page_cleaner

MySQL Error Log 中IO写入瓶颈的警告分析

在一台MySQL实例上频繁做大批量的写入测试，无意中发现MySQL的errorlog中频繁出现如下的Note：
page_cleaner: 1000ms intended loop took **** ms. The settings might not be optimal. (flushed=**** and evicted=0, during the time.)

 

一个典型的信息如下

InnoDB: page_cleaner: 1000ms intended loop took 4068ms. The settings might not be optimal. (flushed=2000 and evicted=0, during the time.)
该告警意味着MySQL实例按照目前IO相关的参数配置的前提下，存在着IO写入性能上的瓶颈，配置参数与IO处理能力不匹配。
因为很清楚是在做测试的情况下，连续大批量写入数据造成的，很有可能是checkpoint刷新脏页造成IO不足的警告。

page_cleaner超时只是果，而不是因，一个果可能是有不同的因造成的，具体原因在哪里？
逐步反推这个过程：单次刷新内存数据到磁盘的数量过大<----LRU刷新或者脏页刷刷新<------大批量读写数据（LRU）或者删除出数据（delete，drop等等））。
另外一个原因（删除数据造成的page_cleaner超时）参考：https://www.cnblogs.com/wy123/p/11763293.html

MySQL在正常运行时4个与IO写入（checkpoint）相关的参数，然后逐一分析其写入的时机和内存页面的数量。

1，innodb_io_capacity

master thread中每秒或者每10s循环中刷新脏页的数量

 那么master thread中定时循环刷新脏页的数据是多少？由参数innodb_io_capacity决定，

2，innodb_max_dirty_pages_pct

innodb buffer pool中脏页数量超过这个比例之后，刷新部分脏页到磁盘。

这种情况下刷新的“部分”脏页，到底是刷新多少个脏页？
因为没有阅读源码的能力，从这里来看（后面会给出参考链接），这个值是依旧是innodb_io_capacity个脏页。

innodb_max_dirty_pages_pct这个参数本身（75%）默认值差不多就是最优化的，应该是不能瞎调的。以下截图自《MySQL技术内幕InnoDB存储引擎》page 42

3，innodb_lru_scan_depth

lru列表中保持空闲page的数据量，如果低于这个数量，则按照LRU的原则刷新脏页到磁盘。
这种情况下是刷线多少个脏页？
（20190906补充：这句话是有问题的的，LRU的刷新跟脏页是没有必然关系，LRU只是脏冷数据从bufferpool中移除掉）LRU只关心页的冷热程度，而不关系页是否为脏页。
此情况下触发，默认扫描innodb_lru_scan_depth个lru冷端数据页，将脏页（扫描到的innodb_lru_scan_depth个冷数据页面中，如果是脏页的话）写入磁盘(有10个就刷10，有100个就刷100个……)
 

4，redo log日志空间达到配置阈值的刷新（一个实例的redo log空间总和）

单个redo log大小的参数：innodb_log_file_size
redo log 个数：innodb_log_files_in_group 
async_water_mark 　　= 75%*innodb_log_file_size
sync_water_mark 　　 = 90%*innodb_log_file_size
　 1）当checkpoint_age 　 2）当async_water_mark 　 3）当checkpoint_age>sync_water_mark的时候，执行sync Flush checkpoint。也就说，redo log剩余空间不足10%的时候，执行Sync Flush checkpoint，刷新到满足条件1。

在buffer pool远没有达到分配值的情况下，innodb_max_dirty_pages_pct和innodb_lru_scan_depth也不会达到checkpoint的条件，redo log也没有切换，
因此只能断定为master thread 后台线程定时刷新脏页造成的IO负担过载，因此尝试 set global innodb_io_capacity = 1000;
经后继续测试观察，尚未发现类似新的page_cleaner告警日志产生。