一 收集手段:
既然出了问题,首先要进行数据问题的收集,所以做好mysql平时数据收集的准备,已方便作为排查问题的手段
1 慢日志的打开(强烈建议),慢日志记录的sql语句对于排查大部分问题相当有帮助,和研发联系讨论也有了根据,是非常必要的。可以用lepus的慢日志切割脚本,按照小时进行切割文件,方面查看。然后进行远程插入到数据库进行备份。被切割的慢日志进行定期删除
2 processlist的收集(建议),对于processlist的收集为每分钟,可能语句执行很快不会记录,但是对于查看当时执行的情况依然会有帮助,尤其是执行的耗时等待
3 对于一些全局变量的把握收集,并绘制成图表,用于展示数据库的一些性能变化。推荐参数(thread_running,thread_wait,qps,tps,open_tables) 收集你认为对数据库影响的性能参数
4 对于linux服务器本身的监控包括 cpu,IO,network,流量和RAID磁盘阵列的监控情况(尤其注意硬盘成员是否健康和raid卡电池的充放电,否则可能导致性能问题甚至down机)
总结:针对以上的监控数据的收集,我们的情况是check_mk(一款新型监控软件)搭配天兔(二次开发)综合监控,check_mk用以弥补天兔对于硬件资源监控的不足,推荐各位可以采用天兔和zabbix监控,都是比较成熟的产品。
二 解决思路
说完了收集手段,咱们来说解决问题的思路,本文只针对作者本身遇到的一些情况,特殊的情况不在考虑范围内
数据库问题分为两类
1 已经发生过的
情景:XX研发询问,在某个时间段内程序有问题,询问是否某个库有性能问题。
思考方式 :
1 首先要确保监控数据在手
2 第一步查看linux的负载和IO是否在这段时间内有较大波动,硬件是否在短暂故障问题
3 第二步查看mysql的慢日志在这段时间的慢日志进行统计分析,归纳。假如出现大量相同的sql慢日志,进一步explain分析,定位问题,进行优化
4 第三步查看mysql的DML统计曲线图,查看这个时间段的QPS和TPS操作是否较大波动,分析是否由较大并发导致
核心思想 慢日志+并发+磁盘状态+内存状态
2 正在发生的
1 分析脚本
show full processlist"|grep -v 'Sleep'|sed 's/\\n//g'|sed 's/\\t//g'|sed 's/[ ][ ]*/ /g'|awk '$6 > 10 {print $_}' 过滤当前执行时间大于10s的session
select count(*)from information_schema.processlist where info is not null; 过滤统计当前thread_running的个数
select count(*)from information_schema.processlist where info is not null; 过滤统计当前每个db的访问session个数
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS_WAIT ;过滤统计当前 持有锁和锁等待的事物
2 观察linux本身的内存 和IO情况
free -m 观测可用内存和swap应用情况
iostat -d -x -k 2 观测磁盘组 以下指标(TPS,util,iowait)
CPU 耗时
根据 1和2 的处理进行分析
三 总结:
1 测试环境下 某个接口由于程序有问题,频繁调用,导致服务器负载出现飙升。这是由于并发导致的性能问题,和研发联系后恢复正常
2 生产环境下 某个innodb表由于联合主键的问题(需要去掉 然后重新添加),导致大量查询sql变慢,由于慢查询所引起的查询堆积,导致业务部可用,和研发联系后,增加自增列作为主。这是典型因为慢查询堆积所引起的性能问题
3 生产环境下 某个表(myisam引擎),并发量大 导致出现大量table lock等待,和研发联系后,转为innodb引擎,业务变快,性能恢复正常,这是由于引擎设置不当所引起的问题
4 生产环境下 某些sql语句对于一张2000万的表进行扫描,虽然走了索引,但是不是最优,优化后性能提升,选择合适的索引是非常重要的
我所遇到的mysql性能问题 大部分都是 1 并发太大 2 慢查询所引起的sql堆积 3 非innodb引擎 4 不合适的索引 5 对大表进行拆分
以上为我的遇到的一些案例和感悟,请诸君点评
原文出处:http://www.cnblogs.com/danhuangpai/p/7510161.html