一 检查和排错过程
客户现场反馈,top的检查结果中,一个CPU的占用一直是100%。实际上现场有4个CPU,而且这个服务器是mysql专属服务器。
我的第一反应是io_thread一类的参数设置有问题,检查以后发现read和write的thread设置都是4,这和CPU数一致,因此可以断定这并不是单颗CPU占用过高的根本原因。
接下来需要确认MySQL究竟有没有利用到多核CPU,这个时候需要的工具叫做pidstat,命令如下:
得到的结果如下图所示:
可以看出其实mysqld是可以利用到多核CPU的,那么此时可以得到一个推断:
某个CPU上做的事情太占资源了
一般这种最占资源的工作一定会在INNODB_TRX里留下一些端倪,因此检查一下:
反复的检查,发现mysql在不停的执行这个SQL,只是where条件里的值发生了变化,至此我可以推断出业务应该是写了一个循环来遍历一个list,然后对每个item都执行update操作。
检查这个表并没有索引,给where条件中的列加上索引,再次检查CPU的占用,发现现在的占用已经降低到了16%左右,虽然还是很高,但是已经实际上解决了该问题。
二 小结
这次首先查io_thread是我的失误,因为这个参数如果没有设置也就是默认情况下也不会把MySQL变成单核的服务。
当然要记住一句话,大部分的CPU异常增高,一定是表没有索引导致的。
BTW,DBA是一个综合技能,除了会MySQL,Oracle之外,还得掌握很多Linux的知识,达到一个中级SA的标准。也不是会写SQL就能当DBA的。
我认识两个大师,一个大师是真的高手,这次这个问题我直接问他的,帮我以最快的速度定位了问题,没有让我走弯路浪费时间,真心感谢;还有一位“大师”。
MySQL真有意思。
领取专属 10元无门槛券
私享最新 技术干货