mysql error log 分析_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.)

55975d5118582fcd6d8313b038592184.png

一个典型的信息如下

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超时只是果,而不是因,一个果可能是有不同的因造成的,具体原因在哪里?

逐步反推这个过程:单次刷新内存数据到磁盘的数量过大

另外一个原因(删除数据造成的page_cleaner超时)参考:https://www.cnblogs.com/wy123/p/11763293.html

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

1,innodb_io_capacity

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

4f529ed55d3140d82082b2e1178f1b8f.png

那么master thread中定时循环刷新脏页的数据是多少?由参数innodb_io_capacity决定,以下截图自《MySQL技术内幕InnoDB存储引擎》page 41

cea6ce924f6caf449349d7c59597d3d0.png

2,innodb_max_dirty_pages_pct

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

8fdb06fc06d0da03e6902b878b501b92.png

这种情况下刷新的“部分”脏页,到底是刷新多少个脏页?

因为没有阅读源码的能力,从这里来看(后面会给出参考链接),这个值是依旧是innodb_io_capacity个脏页。

de61fa576ab759eb51351ae47e59a119.png

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

687e433859b1c53250efe8a1ad13f456.png

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个……)

这一点参考这个(笔者并没有找到确切的证据):https://www.cnblogs.com/geaozhang/p/7341333.html

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。

6d10f4d467bbfdba4f96cc3932d4e154.png

在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告警日志产生。

参考:

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值