{{ item.name }}
{{ item.name }}

{{ it.name }}

{{ it.text }}

{{ it.name }}

{{ innerIt.name }}

{{ innerIt.text }}

{{news.time}}
{{news.title}}
第35问:InnoDB 刷脏页慢,会影响我的业务么?
2021-04-22发布 1,265浏览

关键词:MySQL完全备份MySQL性能监控MySQL运维

问题:

InnoDB 刷脏页刷得比较慢,我的业务会受到影响么?如何进行试验验证?


实验

先宽油建个数据库:


找到这个数据库负责刷脏页的线程号:


我们起一个 gdb(别害怕,本实验没有什么太深的调试技巧)


我们输入以下命令:


前三行命令,允许 gdb 只停下一个线程,而不是停下所有线程。

最后一行 attach,我们让 gdb 管控我们的 MySQL 实例。


经过一堆看不懂的输出,gdb 已经管控了 MySQL 实例,可以输入命令了。

我们先输入 info thread,拿到 MySQL 的线程表,找到负责刷脏页的线程在 gdb 中对应的 ID,是第 13 号线程:


然后我们在 thread 13 上打一个断点(我们为什么知道要在 pc_sleep_if_needed 处打断点呢?留待晚点解释)


紧接着就会看到 thread 13 停在了断点上,这根线程目前就停下来,不会再进行刷脏页了。

再来看一下各个线程的状态,有 1 号线程和 13 号线程停了下来:


我们将 1 号线程放开:


然后将 gdb 放在一边,现在开始给 MySQL 上压力,还是用我们常用的方法:


不停执行最后一句,会发现 insert 会卡住,观察一下 innodb status:


buffer pool 不再刷脏,无读无写。

数据页总共有 7745 页,而脏页总共有 6586 页,看上去还可以释放一些非脏页出来。

观察 redo log 的状态:


redo log 上一次 checkpoint 到当前的位置,一共有(945661967-869887159 =)75774808 字节(75M)。

而我们的 redo log 总大小有将近 100M(50331648*2 = 100663296 字节)。


看上去 redo log 的空闲也够用。

那么为什么我们不能继续进行业务呢?

我们将 innodb metrics 打开:


观察相关的 metrics:


可以看到 innodb 定义的两条水位线:redo log 尚未 checkpoint 的日志大小(modified age)的水位线,一条异步水位线,一条同步水位线(这两条水位线是 innodb 自动算出来的,不要问为什么合理)

当超过异步水位线时,MySQL 开始调动 IO 尽力刷脏页,但业务仍能正常进行;当超过同步水位线时,将阻塞业务等待刷脏页。

我们的场景下,modified age (=75774808) 刚好超过同步水位线,业务均开始阻塞。

至此,我们通过实验,验证了 innodb 刷脏页慢是会阻塞业务的。

江湖上一直有一个传说,处理 SQL 的线程会在紧急的状况下帮助刷脏页。

本实验中我们只停下了一个线程,大家也就可以验证这个传说不十分靠谱,所有的刷脏页都是通过专门的线程进行,处理 SQL 的线程只能提出刷脏页的需求,而不能直接动手。

扩展知识

知识一

推荐阅读 percona 的文章:

https://www.percona.com/blog/2020/01/22/innodb-flushing-in-action-for-percona-server-for-mysql/

此文分析了 innodb 刷脏页的三个原因:脏页比例高、空闲页数低、adaptive flush(通过计算 redo log 的使用度进行不同程度的刷脏页策略),并给予了充分的讨论。

在本实验中,我们触发了 adaptive flush 的水位线,业务因此受到了影响。

知识二

如果大家把这个卡顿的环境放置 10 分钟以上,就会发现 MySQL 崩溃了,error log 显示报错信息为:

当大家碰到 error log 出现 "Semaphore wait has lasted > 600 seconds" 字样时,不能简单判断其是什么原因,本实验是一种可能,还有许多其他可能,需要其他临床现象进行辅助诊断。

优秀的 MySQL DBA 应当远离“算命式运维”的危险思路。

知识三

本实验有两处逻辑跳跃:

我们是怎么确定断点位置是 pc_sleep_if_needed 的?

我们怎么知道 redo log 存在水位线的?

这两个的答案都一样,就是使用 gdb 观察 MySQL 的堆栈。

可以使用 pstack 或者 gdb,观察 MySQL 在刷脏页线程或者 hang 住时候的堆栈,加以简单分析。

运维建议

建议大家将 InnoDB 刷脏页的三种原因和刷脏程度加入监控系统,可以据此分析业务是否由于这个原因受到影响。

关键词:MySQL完全备份MySQL性能监控MySQL运维

上一篇
分布式 | 关于 druid 连接池参数问题
400-820-6580 13916131869
marketing@actionsky.com
上海市闵行区万源路2138号泓茂中心2号楼
产品详情
关系型数据库
AI数据库
数据库智能管理平台
数据库生态产品
行业案例
金融行业
新零售行业
制造业
通信行业
更多
公司动态
最新新闻
国产化信息
技术分享
关于我们
公司简介
公司分布
国家专利
资质认证
扫码关注公众号
© Copyright 2017, All rights reserved by: 上海爱可生信息技术股份有限公司 沪ICP备12003970号-1 | 法律声明 | 网站地图
沪公网安备 31010402003331号