SSD 下的 MySQL IO 优化尝试

　　5.6 关闭 innodb_adaptive_flushing
　　修改方法如下：
　　SET GLOBAL innodb_adaptive_flushing = OFF;
　　修改之后的 MySQL 配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 1500
　　innodb_max_dirty_pages_pct 25
　　innodb_adaptive_flushing OFF
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　既然落地仍然有异常，那我们可以试着关闭 innodb_adaptive_flushing，不让 MySQL 干预落地。调整的结果是，脏数据该落地还是落地，并没有受 I/O 压力的影响，调整此参数无效。
　　5.7 打开 innodb_adaptive_flushing
　　修改方法如下：
　　SET GLOBAL innodb_adaptive_flushing = ON;
　　修改之后的 MySQL 配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 1500
　　innodb_max_dirty_pages_pct 25
　　innodb_adaptive_flushing ON
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　经过以上调整，关闭 innodb_adaptive_flushing 没有效果，还是保持默认打开，让这个功能持续起作用吧。
　　5.8 设置 innodb_max_dirty_pages_pct = 20
　　修改方法不赘述。
　　修改之后的 MySQL 配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 1500
　　innodb_max_dirty_pages_pct 20
　　innodb_adaptive_flushing ON
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　接着我们将 innodb_max_dirty_pages_pct 下调为 20，观察脏数据情况。由于 InnoDB Buffer Pool 设置为 40G，20% 也是 8G，此时的压力达不到此阀值，所以调整参数是没有效果的。但业务繁忙时，可以看到效果，落地频率会增高。
　　5.9 设置 innodb_io_capacity = 1000
　　修改方法不赘述。
　　修改之后的 MySQL 配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 1000
　　innodb_max_dirty_pages_pct 20
　　innodb_adaptive_flushing ON
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　经过以上调整，我们需要的是一个均衡的 IO，给其他进程一些余地。于是把 innodb_io_capacity 设置为 1000，此时可以看到 I/O until 维持在 10% 左右，整个系统的参数趋于稳定。
　　后续还要做进一步的监控、跟踪、分析和优化。
　　6、 程序切换之后调优
　　在业务低峰，凌晨 1 点左右，配合研发做了切换。切换之后的主从关系可以查看第五节。
　　6.1 设置 innodb_max_dirty_pages_pct = 30，innodb_io_capacity = 1500
　　修改方法不赘述。
　　修改之后的 MySQL 配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 1500
　　innodb_max_dirty_pages_pct 30
　　innodb_adaptive_flushing ON
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　在 innodb_io_capacity 为 1000，innodb_max_dirty_pages_pct 为 20 的环境下，I/O until 有小幅波动，而且波峰和波谷持续交替，这种情况是不希望看到的。innodbBuffPoolPagesFlushed 比较稳定，但 innodbBuffPoolPagesDirty 持续上涨，没有下降的趋势。故做了如下调整：innodb_max_dirty_pages_pct = 30，innodb_io_capacity = 1500。调整完成后，innodbBuffPoolPagesDirty 趋于稳定，I/O until 也比较稳定。
　　6.2 设置 innodb_max_dirty_pages_pct = 40，innodb_io_capacity = 2000
　　修改方法不赘述。
　　修改之后的 MySQL 配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 2000
　　innodb_max_dirty_pages_pct 40
　　innodb_adaptive_flushing ON
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　针对目前这种 I/O 情况，做了如下调整：innodb_max_dirty_pages_pct = 40，innodb_io_capacity = 2000。
　　6.3 分析
　　针对以上两个调整，我们通过结合监控数据来分析 I/O 状态。
　　以下是高速缓冲区的脏页数据情况，如图二：

　　图二 主库的脏数据情况
 

　　以下是脏数据落地的情况，如图三

　　图三 主库的脏数据落地情况

　　28 号早 8 点到下午 7 点，当脏数据上升，也是在内存中的数据更多，那么落地会很少，呈现一个平稳的趋势；当脏数据维持不变，也是脏数据达到了 innodb_max_dirty_pages_pct 的限额（innodb_buffer_pool_size 为 40G，innodb_max_dirty_pages_pct 为 40%，也是在内存中的脏数据多为 16G，每个 Page 16K，则 innodbBufferPoolDirtyPages 大为 1000K），落地会增多，呈现上升的趋势，所以才会出现上述图片中的曲线。
　　这是后的配置：
　　innodb_buffer_pool_size 42949672960
　　innodb_log_file_size 1342177280
　　innodb_io_capacity 2000
　　innodb_max_dirty_pages_pct 40
　　innodb_adaptive_flushing ON
　　innodb_write_io_threads 4
　　innodb_read_io_threads 4
　　7、小结
　　此次针对 SSD 以及 MySQL InnoDB 参数优化，总结起来，也是以下三条：
　　修改系统 I/O 调度算法；
　　分析 I/O 情况，动态调整 innodb_io_capacity 和 innodb_max_dirty_pages_pct；
　　试图调整 innodb_adaptive_flushing，查看效果。
　　针对 innodb_write_io_threads 和 innodb_read_io_threads 的调优我们目前没有做，我相信调整为 8 或者 16，系统 I/O 性能会更好。
　　还有，需要注意以下几点：
　　网络文章介绍的方法有局限性和场景性，不能亲信，不能盲从，做任何调整都要以业务优先。保证业务的平稳运行才是重要的，性能都是其次；
　　任何一个调整，都要建立在数据的支撑和严谨的分析基础上，否则都是空谈；
　　这类调优是非常有意义的，是真正能带来价值的，所以需要多下功夫，并且尽可能地搞明白为什么要这么调整。
　　文末，说一点比较有意思的。之前有篇文章提到过 SSDB。SSDB 底层采用 Google 的 LevelDB，并支持 Redis 协议。LevelDB 的设计完全是贴合 SSD 的设计思想的。首先，尽可能地转化为连续写；其次，不断新增数据文件，防止同一位置不断擦写。另外，SSDB 的名字取得也很有意思，也很有水平。我猜想作者也是希望用户将 SSDB 应用在 SSD 上吧。
　　8、参考
　　MySQL 文档： 8.5 Optimizing for InnoDB Tables
　　（题图来自：pachosting.hk）