案例背景:
线上某台mysql生产库服务器,CPU负载告警,使用率 持续 接近100%,丝毫没有回落的意思!
1. 性能表象的数据采集
登陆DB服务器 : 、mysql进程的CPU占用率765.9%(8核),CPU基本上消耗殆尽!
2. 问题全面诊断:
结论:
内存,磁盘都不是问题,中断请求数还算可以接受,CPU出现性能瓶颈,有大量任务等待CPU时间片;
基本上可以断定是单纯的CPU问题,且是由于mysql进程引发;
根据CPU负载模型,可以断定出问题的地方:(用户态的CPU使用率是瓶颈)
1. mysql进行大量的内存操作,逻辑读;例如:缺失关键索引
2. 大量的CPU运算任务;例如:2表的笛卡尔积
3. MySQL层性能采集
此处可以考虑使用慢日志,由于磁盘不是瓶颈,不会带来太大的额外负载;
这里我采用tcpdump和pt-query-digest来抓问题SQL;
监控:
tcpdump -i eth0 -s 65535 -x -nn -q -tttt port 3306 -c 200000 > 1.dmp &
分析:
pt-query-digest --type tcpdump 1.dmp --limit 10 > report.log
基本上搞定TOP2SQL,问题就能得到缓解;
这2语句的执行时间基本是在1S的样子,且消耗了大量CPU时间:
SQL优化:
TOP 1 SQL
同一个表访问了N次,且是select *,想必大家都知道怎么优化了吧!(吐槽一下!)
TOP 2 SQL
该语句基本上是全表扫描,优化的余地不多;select * 是一个,建一个复合索引,使用索引扫描替换全表扫描
4. 解决办法
临时停止相应的业务,将优化方案提给开发部门!
线上某台mysql生产库服务器,CPU负载告警,使用率 持续 接近100%,丝毫没有回落的意思!
1. 性能表象的数据采集
登陆DB服务器 : 、mysql进程的CPU占用率765.9%(8核),CPU基本上消耗殆尽!
2. 问题全面诊断:
结论:
内存,磁盘都不是问题,中断请求数还算可以接受,CPU出现性能瓶颈,有大量任务等待CPU时间片;
基本上可以断定是单纯的CPU问题,且是由于mysql进程引发;
根据CPU负载模型,可以断定出问题的地方:(用户态的CPU使用率是瓶颈)
1. mysql进行大量的内存操作,逻辑读;例如:缺失关键索引
2. 大量的CPU运算任务;例如:2表的笛卡尔积
3. MySQL层性能采集
此处可以考虑使用慢日志,由于磁盘不是瓶颈,不会带来太大的额外负载;
这里我采用tcpdump和pt-query-digest来抓问题SQL;
监控:
tcpdump -i eth0 -s 65535 -x -nn -q -tttt port 3306 -c 200000 > 1.dmp &
分析:
pt-query-digest --type tcpdump 1.dmp --limit 10 > report.log
基本上搞定TOP2SQL,问题就能得到缓解;
这2语句的执行时间基本是在1S的样子,且消耗了大量CPU时间:
SQL优化:
TOP 1 SQL
同一个表访问了N次,且是select *,想必大家都知道怎么优化了吧!(吐槽一下!)
TOP 2 SQL
该语句基本上是全表扫描,优化的余地不多;select * 是一个,建一个复合索引,使用索引扫描替换全表扫描
4. 解决办法
临时停止相应的业务,将优化方案提给开发部门!