大家好,我是考100分的小小码 ,祝大家学习进步,加薪顺利呀。今天说一说第03问:磁盘 IO 报警,MySQL 读写哪个文件慢了?[亲测有效],希望您对编程的造诣更进一步.
问题:
磁盘 IO 报警,说 IO 饱和了。 那么 MySQL 读写哪个文件慢了?binlog?redo log?还是哪张表?
构造环境:
根据先前的 实验 02,构造环境,模仿 binlog 的磁盘 IO 慢。
实验:
想观察 IO 相关的行为,需启用 performance_schema 的 instrument(生产者)和 consumer(消费者)。将 performance_schema 的配置重置为默认配置,IO 相关的 instrument(生产者)在默认配置里开启。
启用 waits 相关的 consumer(消费者)
将已记录的性能数据清零
向 MySQL 施加压力
在另一个 session 中,观察最近的 IO 行为。
可以看到 binlog 的刷盘 IO 明显比其他操作慢,符合我们构造的实验场景。这样我们就快速定位了哪个文件的 IO 变慢了。有了线程号,我们还可以定位其对应的操作:
结论:
我们通过 sys.x$latest_file_io,找到最近的 IO 操作的记录,进行了排序。 需注意:
- 这里不用 sys.latest_file_io 的原因是无法对操作延迟进行排序。
小知识: 以 sys 中, 以 x$ 开头的视图,是原始数据。
不以 x$ 开头的视图,是给人类看的视图(比如时间显示会带单位,显示成 123 ns)。
- sys.x$latest_file_io 视图涉及到两张表:
performance_schema
. events_waits_history_long
和 performance_schema
. threads
如果某个线程退出,就不会出现在 sys.x$latest_file_io 视图。
所以 sys.x$latest_file_io 不是”最近的 IO 操作记录”,而是”当前活跃线程的最近的 IO 操作记录”。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/9539.html