排查Mysql突然变慢的一次过程
排查Mysql突然变慢的一次过程 本文源地址: 排查Mysql突然变慢的一次过程 上周客户说系统突然变得很慢,而且时不时的蹦出一个 404 和 500 ,弄得真的是很没面子,而恰巧出问题的时候正在深圳出差,所以一直没有时间 看问题,一直到今天,才算是把问题原因找到。 定位问题 刚开始得到是系统慢的反馈,没有将问题点定位到数据库上,查了半天服务是否正常(因为之前有一次Dubbo内存泄漏)。 在将应用服务日志查看了一遍后,没有发现任何异常,只是打了几个警告的日志。 于是又查看了业务运行时的日志,看到日志都提示了一个 Lock wait timeout exceeded; try restarting transaction 的异常。 这时还是没有将重心放到数据库上,认为是代码的原因,导致事务一直没有提交。 重新将代码审阅了一遍,觉得应该不是代码逻辑的问题,而这个时候, Lock wait timeout exceeded; try restarting transaction 这个异常的日志越来越多。 认为是数据库层面出了问题,开始排查数据库。 寻找原因 由于我们的数据库不是用的 云RDS版本 ,是在一台8核32G的AWS上的安装版本。 使用 top 命令,查看到 Mysql 占用的 CPU 使用率高达 90% 左右。 心里一慌,感觉不妙,这样子高负载的CPU使用率