客户现场反馈, top 的检查结果中, 一个 CPU 的占用一直是 100%. 实际上现场有 4 个 CPU, 而且这个服务器是 MySQL 专属服务器.
我的第一反应是 io_thread 一类的参数设置有问题, 检查以后发现 read 和 write 的 thread 设置都是 4, 这和 CPU 数一致, 因此可以断定这并不是单颗 CPU 占用过高的问题.
接下来需要确认 MySQL 究竟有没有利用到多核 CPU, 这个时候需要的工具叫做 pidstat, 命令如下:
pidstat -u -t -p 18158
得到的结果如下图所示:
可以看出其实 mysqld 是可以利用到多核 CPU 的, 那么此时可以得到一个推断:
某个 CPU 上做的事情太占资源了
一般这种最占资源的工作一定会在 INNODB_TRX 里留下一些端倪, 因此检查一下:
反复的检查 TRX, 发现 MySQL 在不停的执行这个 SQL, 只是 where 条件里的值发生了变化, 至此我可以推断出业务应该是写了一个循环来遍历一个 list, 然后对每个 item 都执行 update 操作.
应该是写了这么一段代码在处理问题:
- for (item in list) {
- update_db(item);
- }
检查这个表并没有索引, 给 where 条件中的列加上索引, 再次检查 CPU 的占用, 发现现在的占用已经降低到了 16% 左右, 虽然还是很高, 但是已经实际上解决了该问题.
这里我有点感慨, DBA 并不是你会写 SQL 就可以干的, DBA 实际上是运维人员的一种, 运维要掌握多少种技能恐怕只有运维小伙伴们清楚, 其实技术难度并不比写 Java 代码低. DBA 掌握多少种检查问题的手段, DBA 面对问题时能不能第一时间找准方向, 这都是经验和功力的展现.
来源: http://www.linuxidc.com/Linux/2018-12/155811.htm