这篇文章主要介绍mysql服务器的性能分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
3.3.3使用性能剖析:有限
3.4诊断简歇性问题
如系统偶尔停顿,慢查询,唤影问题,尽量不要使用试错的方式解决问题:风险大
3.4.1单条查询问题还是服务问题
使用显示全球状态
较高频率:1 s/次执行该命令铺获数据,问题出现通过计数器的
使用显示PROCESSLIST【参考】显示哪些线程正在运行
使用查询日志
开启慢查询,设置全局的long_query_time=0,确认所有连接采用了新设置(可能需要重置所有连接使生效)
注意吞吐量突然下降时间段的日志,查询是在完成阶段才写入到慢查询日志的
好的工具事半功倍:tcpdump, pt-query-digest, Percona服务器
理解发现的问题
可视化数据:gnuplot/R(绘图工具)
gnuplot:
安装,,一些命令:,常用技巧,,,入门教程2,,,,Gnuplot,,,数据可视化
建议:先使用前两种方法,开销低且通简单壳脚本或反复执行的查询交互式收集数据
3.4.2铺获诊断数据
现间歇性问题,尽量多收集数据(不只是问题出现时的)
弄清楚:1,有区分何时出现了问题,的方法:触发器;2,收集诊断数据的工具
诊断触发器
误差:在没有发生问题期间收集了很多诊断数据,浪费时间(这个和前的,仔细读一下不矛盾)
漏检:在问题出现时没有铺获到数据,错失了机会,开始收集前确认触发器能够真正地识别问题
<强>好的触发器:
找到些能和正常时的阈值进行比较的指标
选择一个合适的阈值:足够高(正常时不会触发),不能太高(问题发生时不错过)
推荐工具pt-stalk【参考】【2】触发器,设定到某个条件记录配置需监控的变量阈值检查的频率
收集什么样的数据
<>强执行时间:工作的时间和等待的时间
<强>在需要的时间段内收集所有能收集的数据
<强>未知问题发生的原因:1,服务器需做大量工作,导致大量消耗CPU; 2、在等待资源释放
不同的方法收集诊断数据,确认原因:
1,剖析报告:确认是否有太多工作,工具:tcpdump监听TCP流量模式开闭慢查询日志
2,等待分析:确认是否存在大量等待,GDB堆栈跟踪信息,显示processlist,,显示innodb状态观察线程,事务状态
解释结果数据
目的:1,问题是否真的发生了;2,是否有明显的跳跃性变化
<强>工具:
<强> oprofile 强利用CPU硬件层面提供的性能计数器(性能计数器),通过计数采样,帮助我们从进程,函数,代码层面找出占用CPU的“罪魁祸首“。实例【参考】
opreport命令,分别从进程和函数层面查看CPU使用情况的方法
opannotate命令可显示代码层面占用cpu的统计信息
GDB:Linux应用程序开发中，最常用的调试器是gdb(调试的对象是可执行文件)，它可以在程序中设置断点、查看变量值、一步一步跟踪程序的执行过程(数据、源码）、查看内存、堆栈信息。利用调试器的这些功能可以方便地找出程序中存在的非语法错误。【参考】【参考】 语法和实例
3.4.3一个诊断案例
间歇性性能问题，具备MySQL、innodb、GNU/Linux相关知识
明确：1、问题是什么，清晰描述；2、为解决问题已做过什么操作？
开始：1、了解服务器的行为；2、梳理服务器的状态 参数配置 软硬件环境（pt-summary pt-mysql-summary）
不要被离题太多的各种情况分散了注意力，问题写在纸条上，检查一个划掉一个
是原因还是结果？？？
资源变得效率低下可能的原因：
1、资源过度使用，余额不足；2、资源未被正确匹配；3、资源损坏或失灵
3.5其他剖析工具
USER_STATISTICS:一些表对数据库活动进行测量、审计
strace：调查系统调用情况，使用实际时间、不可预期性、开销的，oprofile使用花费CPU周期
