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周期

小结：

• 定义性能最有效的方法是响应时间

• 无法测量便无法有效优化，性能优化工作需要基于高质量、全方位及完整的响应时间测量

• 测量的最佳开始点是应用程序，即使问题出在底层的数据库，借助良好的测量较容易发现问题

• 大多数系统无法完整地测量，测量有时候也会有错误的结果，想办法绕过些限制，要能意识到方法的缺陷和不确定性在哪

• 完整的测量会产生大量需要分析的数据，so需要用到剖析器（最佳工具）

• 剖析报告：汇总信息，掩盖和丢弃了很多细节，不会告诉你缺了什么，不能完全依赖

• 两种消耗时间的操作：工作或等待，almost剖析器只能测量因工作而消耗的时间，so等待分享有时候是很有用的补充，特别是cpu利用率低但工作一直无法完成的情况

• 优化和提升两回事，当继续提升的成本超过收益时，应停止优化

• 注意你的直接，思路，决策尽量基于数据

in a words:首先澄清问题、选择合适技术、善用工具、足够细心、逻辑清晰且坚持下去，不要把原因和结果搞混，在确定问题前不要随便针对系统做变动

相关文章：

【MySQL数据库】第二章解读：MySQL基准测试

【MySQL数据库】第三章解读：服务器性能剖析（上）

以上就是【MySQL数据库】第三章解读：服务器性能剖析 （下）的详细内容，更多请关注php中文网其它相关文章！