读书笔记《高性能MySQL》第三章 服务器性能剖析

  问10个人关于性能的问题,可能会得到10个不同的回答,比如“每秒查询次数”、“CPU利用率”、“可扩展性”之类的。这其实都没有问题,每个人在不同场景下对性能都有不同的理解。本书的作者将性能定义为:完成某件任务所需的时间度量,换句话说,性能即是响应时间。
  很多人对什么是优化很迷茫,假如你认为性能优化是降低CPU利用率,这样就可以减少对资源的使用。但这是一个陷阱,资源是用来消耗并工作的,所以,有时候如果消耗更多的资源,就能够加快查询的速度,也是可取的。

性能剖析一般有两个步骤:
  1、测量任务所花费的时间;
  2、对结果进行统计和排序,将重要的任务排到前面。

尽管性能剖析输出了排名、总计和平均值,但还是有很多需要的信息是缺失的,如下所示:
  1、值得优化的查询:性能剖析不会自动给出哪些查询值得花时间去优化。一些占总响应时间比重较小的查询,是不值得优化的,根据阿姆达尔定律,对一个占总响应时间不超过5%的查询进行优化,无论如何努力,收益也不会超过5%。如果优化的成本大于收益,就应当停止优化。
  2、异常情况:某些任务,即使没有出现在性能剖析输出的前面,也需要优化。比如,某些任务执行的次数很少,但每次执行都非常慢,严重影响用户体验。因为其执行频率低,所以总的响应时间占比并不突出。
  3、未知的未知:一款好的性能剖析工具会显示可能的“丢失时的间”。丢失的时间指的是,任务的总时间和实际测量到的时间之间的差。例如,如果处理器的CPU时间是10秒,而剖析到的任务总时间是9.7秒,那么就有300毫秒的丢失时间。这可能是有些任务没有测量到,也可能是由于测量的误差和精度问题的缘故。如果工具发现了这类问题,则要引起重视,因为有可能错过了某些重要的事情。即使性能剖析没有发现丢失时间,也需要注意考虑这类问题存在的可能性,这样才不会错过重要的信息。
  4、被掩藏的细节:性能剖析无法显示所有响应时间的分布。只相信平均值是非常危险的,它会隐藏很多信息,而且无法表达全部情况。Peter经常举例说医院所有病人的平均体温没有任何价值。

性能瓶颈可能有很多影响因素:
  1、外部资源,比如调用了外部的web服务或搜索引擎;
  2、应用需要处理大量的数据,比如分析一个超大的XML文件;
  3、在循环中执行昂贵的操作,比如滥用正则表达式;
  4、使用了低效的算法,比如使用暴力搜索算法,来查找列表中的项;

测量工具:New Pelic、xhprof、xdebug、Valgrind、cachegrind、Enterprise Monitor( 它是Oracle提供的MySQL商业服务支持中的一部分 )

剖析MySQL查询:
  1、慢查询日志,可以通过设置long_query_time为0来捕获所有的查询。它是开销最低、精度最高的测量查询时间的工具,但它并不是万能的。例如,当数据库负载已经过高时,即使原本执行速度非常快的查询,也有可能会变的很慢;
  2、抓取TCP网络包,可以先通过tcpdump将网络包数据保存到磁盘,然后使用pt-query-digest的–type=tcpdump选项来解析并分析查询。此方法精度比较高,并且可以捕获所有查询。还可以解析更高级的协议特性,比如可以解析二进制协议,从而创建并执行服务端预解析的语句及压缩协议;
  3、使用show profile,它是在MySQL5.1以后的版本引入的,来源于开源社区的Jeremy Cole的贡献。此命令非常强大,可以分析查询语句具体慢在哪里。例如:是创建临时表慢、还是执行排序慢;
  4、使用show status,这个命令会返回一些计数器。既有服务器级别的全局计数器,也有基于某个连接的会话级别的计数器。它可以分析出,查询语句创建了多少张临时表,是磁盘临时表,还是内存临时表,几条结果用到索引的读操作,几条结果没有用到索引的读操作,也非常强大;
  5、使用explain,它能分析语句的执行计划。可以判断语句是否有用到索引,用了哪些索引,索引的长度,所需扫描的记录数,等等;
  6、使用show processlist,可以通过该命令,来观察是否有大量线程处于不正常的状态,或有其它不正常的特征。例如,查询很少会长时间处于statistics状态;

  MySQL的性能剖析,除了对单条查询语句本身,需要做详细的分析以外,有的时候还需要对整个应用程序,甚至整个MySQL服务或服务器做分析。就像作者说的,没有什么是放之四海而皆准。找到确定的问题点,然后使用正确而有效的方法,就能做到以不变而应万变。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注