1. MySQL故障诊断案例
DBA学院课程之：
淘宝希羽
2012-10-17

2. MySQL无故被kill – 现象
• MySQL实例宕机，检测到日志中是由mysqld
被kill -9导致
• 如何排查？

3. MySQL无故被kill – 原因
• ulimit 有异常参数
$ ulimit -t
300
• -t的含义
– The maximum amount of cpu time in seconds
– 实际上为，进程消耗cpu的总量，达到阈值后会
自己被kill
• 扩展

4. MySQL无故被shutdown – 现象
• MySQL实例宕机，检测到日志中是mysqld被
正常的shutdown
• 如何排查？

5. MySQL无故被shutdown – 排查
• 定位问题的触发点
– 批量升级agent，导致集群中一台机器被
shutdown(时间点吻合)
• 查看dbagent代码(关注各种kill)
• 各种猜测+验证

6. MySQL无故被shutdown – 结果
restart机器后, mysqld的pid和agent老的pid(agent的pid文件未被删除)相同
例如：
重启前：agent pid=1000, mysqld pid=10001
重启后：agent pid=1000, mysqld pid=10000

7. MySQL机器内存爆掉—现象
MySQL机器的内存每隔几天就会增长，
涨上去后，却不下来。累积后内存爆掉。

8. MySQL机器内存爆掉 -- 思考
• 近期升级过kernel的因素？
• innodb内部统计的内存使用量
• NUMA开关导致swap？
• 临时表、memory引擎表？
• 连接所消耗内存？
• table cache相关的内存？
• 真正的mysqld内存泄漏？
• … 其它

9. MySQL机器内存爆掉—解决
执行FLUSH TABLES发现mysqld的RSZ直接
减少10G~
定时在业务低峰时flush tables

10. Communications link failure – 现象
MySQL APP业务线上最近抛出异常

11. Communications link failure – 现象
Information Schema库中的InnoDB_trx表，发现发现有不少
已经开启的事务：

12. Communications link failure – 本质
• 认识上的误区：在autocommit=0时，即使
是select也要注意，显示地提交事务！
• 详情

13. MySQL上dump数据缓慢 – 现象
MySQL群集中某台机器拉数据明显地比其它机器慢
怎么办？
对比集群中的运行环境

14. MySQL上dump数据缓慢– 对比
IO调度策略改变后的对比

15. CFQ和DEADLINE的对比 --小结
• CFQ通过对IO地址排序来减少磁盘寻道时间
– 从rrqm/s和wrqm/s的数据看非常明显
• CFQ先来的IO请求并不一定能被满足
– await明显的偏长
• DEADLINE(或SSD中的NOOP)比CFQ更适合DB
– rsec/s和wsec/s比CFQ中量更大
• 详情

16. 对同一条记录的更新慢 – 现象
• 现象表现
- 应用有个别连接间断性报错：锁等待超时错误
（超过100s)
- slow.log中大量的相同同一条记录更新语句：
update dep_deposit set
gmt_modified=now(), seller_id=xxx, ...
where id=239758;
• “热卖商品”死锁补丁？？？

17. 对同一条记录的更新慢 --疑点
• 疑点1：
– 从业务方了解，此记录为热门退货的某条记录，
集中段在有大量的商品退货：
14点：203次 （出现异常）
13点：22次
12点：9次
• 疑点2
– innodb status的DEADLOCK DETECT无“检测递归
深度过大”字样

18. 对同一条记录的更新慢 – 解决
• APP应用在MySQL的事务中嵌套了对TAIR的
访问
– TAIR慢而导致事务中个别未提交事务
– 引发其它锁相关的问题
• 将不合理的TAIR依赖从事务中移除
• 详情

19. MySQL-5.5多实例频繁发生swap

20. MySQL-5.5多实例频繁发生swap
• 将BP从12G改为10G
• 详情