二进制日志和文件系统是如何影响MySQL的性能的(译自Percona)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 基准测试的设置概览如下

01

基准测试的设置


基准测试的设置概览如下:

  • Percona Server for MySQL 5.7.21
  • InnoDB 存储引擎
  • 启用了外键,使用可重复读取隔离级别,并使用了 UTF8 字符集。
  • 数据集:sysbench-tpcc 有 10 个表和 100个仓库,总共有 1000个仓库,数据集大小约为90GB。
  • 使用 80GB、70GB 和 60GB innodb_buffer_pool_size来模拟不同的 IO 负载,并评估这对二进制日志写入的影响。


02

初步结果


第一次测试,对比没有启用二进制日志与启用二进制日志(设置 sync_binlog=0) :

我们可以看到没有启用二进制日志的性能通常略好。另一个值得注意的现象是,启用二进制日志且 sync_binglog=0 的情况下,每40秒会出现吞吐量下降到0,并持续 1-2 秒,这时基本上任何连接的应用都会停滞。原因是二进制日志文件 (max_binlog_size) 的大小有限制,即 1GB。当达到1GB的限制时,MySQL会执行二进制日志轮换。因为使用 sync_binlog=0 ,以前对二进制日志的所有写入都缓存在操作系统缓存中,在二进制轮换时,MySQL 强制同步刷新所有的更新到磁盘,这导致每 40 秒应用完全停止一次,40秒是在上述测试中填满 1GB 二进制日志所需的时间。我们该如何解决这个问题?显而易见的解决方案是更频繁地进行二进制日志的同步写入,这可以通过将sync_binlog设置为>0来实现。流行的选择是sync_binlog=1,这时每次提交都会写二进制日志,它可以最大限度的保护数据,但伴随着明显的性能下降。我将测试 sync_binlog=1000 和 sync_binlog=10000,这意味着分别每 1000 和 10000 个事务各执行一次二进制日志的同步写入。


03

测试结果

下面用表格的方式列出吞吐量的中位数(tps越多性能越好)


InnoDB缓存/ sync_binlog 0
1
1000
10000
无二进制日志
60GB 4174.945 3598.12 5263.375 4205.165 4277.955
70GB
5053.11
4541.985 4997.87 4997.87 5328.96
80GB 5701.985 5263.375 5303.145 5664.155 6087.925

我们可以得出一些结论:

  • sync_binlog=1 的性能损失最大,但差异最小,这与在没有二进制日志的情况下运行相当。
  • sync_binlog=0 在已启用的二进制日志时提供最佳的性能,但差异很大。
  • sync_binlog=1000 是一个很好的折衷方案,它以最小的差异提供比 sync_binlog=1 更好的性能。
  • sync_binlog=10000 可能不好,显示的差异比sync_binlog=0 少,但仍然很大。

那么我们应该把sync_binlog设置成什么值呢?这可能是在 sync_binlog=1 或 1000 之间做选择。这取决于您的应用和存储,我这里使用的是enterprise SATA SSD SAMSUNG SM86,但在存储性能比较差的情况下,设置sync_binlog=1对性能的影响更大。


04

件系统


以上所有结果都在 EXT4 文件系统上,让我们与 XFS 进行比较。它会显示不同的吞吐量和差异吗?

下面用表格的方式列出吞吐量的中位数(tps越多性能越好)





sync_binlog Buffer pool(GB) EXT4 XFS
0 60 4174.945 3902.055
0 70 5053.11 4884.075
0 80 5701.985 5596.025
1 60 3598.12 3526.545
1 70 4541.985 4538.455
1 80 5263.375 5255.38
1000 60 3950.19 3620.05
1000 70 4714 4526.49
1000 80 5303.145 5150.11
10000 60 4205.165 3874.03
10000 70 4997.875 4845.85
10000 80 5664.155 5557.61
No binlog 60 4277.955 4169.215
No binlog 70 5328.96 5139.625
No binlog 80 6087.925 5957.015

我们可以观察到一个总体趋势,即 XFS 的吞吐量中位数比 EXT4 差一点,差异几乎相同。

吞吐量的差异很小,您可以使用 XFS 或 EXT4中的任意一种。


05

硬件规


Supermicro 服务器:

  • Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz
  • 2 sockets / 28 cores / 56 threads
  • Memory: 256GB of RAM
  • Storage: SAMSUNG  SM863 1.9TB Enterprise SSD
  • Filesystem: ext4/xfs
  • Percona-Server-5.7.21-20
  • OS: Ubuntu 16.04.4, kernel 4.13.0-36-generic
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
30天前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
188 3
|
1月前
|
存储 关系型数据库 MySQL
提高MySQL查询性能的方法有很多
提高MySQL查询性能的方法有很多
145 7
|
1月前
|
存储 关系型数据库 MySQL
提高MySQL的查询性能
提高MySQL的查询性能
66 4
|
2月前
|
SQL 关系型数据库 MySQL
MySQL 8.0:filesort 性能退化的问题分析
用户将 RDS MySQL 实例从 5.6 升级到 8.0 后,发现相同 SQL 的执行时间增长了十几倍。本文就该问题逐步展开排查,并最终定位根因。
|
7天前
|
缓存 监控 关系型数据库
如何根据监控结果调整 MySQL 数据库的参数以提高性能?
【10月更文挑战第28天】根据MySQL数据库的监控结果来调整参数以提高性能,需要综合考虑多个方面的因素
41 1
|
7天前
|
监控 关系型数据库 MySQL
如何监控和诊断 MySQL 数据库的性能问题?
【10月更文挑战第28天】监控和诊断MySQL数据库的性能问题是确保数据库高效稳定运行的关键
19 1
|
7天前
|
缓存 关系型数据库 MySQL
如何优化 MySQL 数据库的性能?
【10月更文挑战第28天】
25 1
|
19天前
|
存储 关系型数据库 MySQL
优化 MySQL 的锁机制以提高并发性能
【10月更文挑战第16天】优化 MySQL 锁机制需要综合考虑多个因素,根据具体的应用场景和需求进行针对性的调整。通过不断地优化和改进,可以提高数据库的并发性能,提升系统的整体效率。
25 1
|
8天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
43 0
|
9天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第26天】数据库作为现代应用系统的核心组件,其性能优化至关重要。本文主要探讨MySQL的索引策略与查询性能调优。通过合理创建索引(如B-Tree、复合索引)和优化查询语句(如使用EXPLAIN、优化分页查询),可以显著提升数据库的响应速度和稳定性。实践中还需定期审查慢查询日志,持续优化性能。
38 0