合肥网站建设公司 招聘,网站界面设计尺寸规范,网络域名怎么设置,购物app哪个好文章目录 3.1 性能优化简介3.1.1 通过性能剖析进行优化3.1.2 理解性能剖析 3.2 对应用程序进行性能剖析3.3 剖析 MySQL 查询3.3.1 剖析服务器负载捕获 MySQL 的查询到日志文件中分析查询日志 3.3.2 剖析单挑查询使用 SHOW PROFILE #xff08;现已过时#xff09;使用SHOW ST… 文章目录 3.1 性能优化简介3.1.1 通过性能剖析进行优化3.1.2 理解性能剖析 3.2 对应用程序进行性能剖析3.3 剖析 MySQL 查询3.3.1 剖析服务器负载捕获 MySQL 的查询到日志文件中分析查询日志 3.3.2 剖析单挑查询使用 SHOW PROFILE 现已过时使用SHOW STATUS 3.4 诊断间歇性问题3.4.1 单条查询问题还是服务器问题使用SHOW GLOBAL STATUS使用SHOW PROCESSLIST使用查询日志理解发现的问题Making sense of the findings 3.4.2 捕获诊断数据诊断触发器需要收集什么样的数据解释结果数据 3.5 其他剖析工具3.5.1 使用 USER_STATISTICS 表3.5.2 使用 strace 作者总结在他们的技术咨询生涯中最常碰到的三个性能相关的服务请求是
如何确认服务器是否达到了性能最佳状态找出某条语句为什么执行不够快诊断被用户描述成“停顿”、“堆积”或者“卡死”的某些间歇性疑难故障。
性能剖析的一个简单方法是专注于测量服务器的事件花费在哪里使用的技术叫做性能剖析profiling。在本章我们将展示如何测量系统并生成剖析报告以及如何分析系统的整个堆栈stack包括从应用程序到数据库服务器到单个查询。
3.1 性能优化简介
先来看一下我们对性能的定义 性能 即 响应时间完成某个任务所需要的时间度量。这是一个非常重要的原则。 我们通过任务和时间而不是资源来测量性能。数据库服务器的目的是执行 SQL 语句所以它关注的任务是 查询 或者语句如 SELECT 、UPDATE、DELETE 等。数据库服务器的性能用查询的响应时间来度量单位是每个查询花费的时间。
然后简要定义了性能优化为在一定工作负载下尽可能地降低响应时间。注意优化和提升是两回事。当继续提升的成本超过收益的时候应当停止优化。 作者推荐了两篇有关性能优化的文章如今可能有些过时了 Goal-Driven Performance OptimizationOptimizing Oracle Performance (O’Reilly) by Cary Millsap, Jeff Holt 吞吐量 单位时间内的查询数量。正好是我们对性能的定义的倒数。 降低 CPU 等资源的利用率、提升吞吐量可以看作是性能优化的副产品而不是性能优化本身。
性能优化第一步要做的是测量响应时间花在哪里并且应将大部分甚至 90%时间花在这里。如果测量系统获得了足够完整、精确的数据性能问题一般都能暴露出来。如果通过测量没有找到答案那要么是测量方式错了要么是测量得不够完整。
**完成一项任务所需要的时间可以分成两部分执行时间和等待时间。**如果要优化任务的执行时间最好的办法是通过测量定位不同的子任务花费的时间然后优化去掉一些子任务、降低子任务的执行频率或执行时间。而优化任务的等待时间则相对要复杂一些因为等待有可能是由其他系统间接影响导致任务之间也可能由于争用磁盘或者 CPU 资源而相互影响。根据时间花在执行还是等待上的不同诊断也需要不同的工具和技术。性能剖析是确认哪些子任务需要优化的技术。 注意测量的数据很可能是不准确的测量结果有时无法反映真实情况我们仅需要保证测量数据的偏差在可接受范围内并且不影响分析问题。 3.1.1 通过性能剖析进行优化
性能剖析是测量和分析时间花费在哪里的主要方法。性能剖析一般分为两步
测量任务所花费的时间然后按任务的重要程度从高到低对结果进行统计和排序。
性能剖析报告profile report 会列出所有任务列表每行记录一个任务包括任务名、任务的执行时间、任务的消耗时间、任务的平均执行时间以及该任务执行时间占全部时间的百分比按任务的消耗时间进行降序排序。
有两种类型的性能剖析基于执行时间的分析和基于等待的分析。如果可以确定时间大部分花在执行还是等待上另一部分时间的影响相对很小则应集中精力优先处理重要的部分对不重要的部分的优化可以推迟甚至不做。
在性能剖析报告中显示的某些“执行时间”实际上是在等待。例如报告中显示某些 SELECT 查询花费了大量时间深入分析则可能发现时间都花在了等待 I/O 完成上。
对系统剖析前需要确保系统是可测量的。这需要系统提供一些计数器来形成测量点。如果系统内部无法做到可测量化则可从外部测量系统。如果测量失败可以根据对系统的了解做出一些靠谱的猜测。但无论是外部测量还是猜测数据都不是百分百准确的这是系统不透明所带来的风险。
3.1.2 理解性能剖析
性能剖析报告缺失的信息
值得优化的查询。首先一些只占总响应时间比重很小的查询是不值得优化的。根据阿姆达尔定律Amadahl’s Law对一个占总响应时间不超过 5% 的查询进行优化无论如何努力收益也不会超过 5% 。其次如果优化的成本大于收益就应当停止优化。异常情况。某些任务即使没有出现在性能剖析输出的前面也需要优化。例如某些任务执行频率很低但每次执行都很慢严重影响用户体验。“丢失的时间”。一款好的性能剖析工具会显示可能存在的“丢失的时间”。“丢失的时间”指的是任务的总时间和实际测量到的时间的差值。例如如果处理器的 CPU 时间是 10 秒而剖析到的任务总时间是 9.7 秒那么就有 300 毫秒的丢失时间。这可能是有些任务没有测量到也可能是由于测量的误差和精度问题的缘故。被掩藏的细节。性能剖析无法显示所有响应时间的分布。平均值无法表达全部情况。例如测量医院所有病人的平均体温没有任何价值。应追加更多响应时间的信息比如直方图、百分比、标准差、方差、偏差指数等。
推荐使用 pt-query-digest 它在剖析的结果里包含了很多这类细节信息并输出在剖析报告中。
3.2 对应用程序进行性能剖析
对整个应用系统进行性能剖析时建议采自顶向下地进行这样可以追踪自用户发起到服务器响应的整个流程。
建议在所有的新项目中都考虑包含性能剖析的代码。
建议使用诸如 New Relic 、Pinpoint 的应用性能监控分析工具。 APM 是 Application Performance Managment 的缩写即“应用性能管理”。现代的APM体系基本都是参考Google的《Dapper大规模分布式系统的跟踪系统》的体系来实践的。 3.3 剖析 MySQL 查询
3.3.1 剖析服务器负载
服务器端的剖析很有价值因为在服务器端可以有效地审计效率低下的查询。定位和优化“坏”查询能够显著地提升应用的性能也能解决某些特定的难题。还可以降低服务器的整体压力这样所有的查询都将因为减少了对共享资源的争用而受益“间接的好处”。降低服务器的负载也可以推迟或者避免升级更昂贵硬件的需求还可以发现和定位糟糕的用户体验比如某些极端情况。
捕获 MySQL 的查询到日志文件中
在 MySQL 5.1 以上版本中慢查询日志功能已经被加强可以通过设置 long_query_time 为 0 来捕获所有查询 而且查询的响应时间单位已经可以做到微秒级。
在 MySQL 的当前版本中慢查询日志是开销最低、精度最高的测量查询时间的工具。如果长期开启慢查询日志注意要部署 日志轮转log rotation 工具。或者不要长期启用慢查询日志只在需要收集负载样本的期间开启即可。
通用日志在查询请求到服务器时进行记录所以不包含响应时间和执行计划等重要信息。
有时因为某些原因如权限不足等无法在服务器上记录查询。这样的限制我们也常常碰到所以我们开发了两种替代的技术都集成到了 Percona Toolkit 中的 pt-query-digest 中。第一种是通过 --processlist 选项不断查看 SHOW FULL PROCESSLIST 的输出记录查询第一次出现的时间和消失的时间。某些情况下这样的精度也足够发现问题但却无法捕获所有的查询。一些执行较快的查询可能在两次执行的间隙就执行完成了从而无法捕获到。
第二种技术是通过抓取 TCP 网络包然后根据 MySQL 的客户端/服务端通信协议进行解析。可以先通过 tcpdump 将网络包数据保存到磁盘然后使用 pt-query-digest 的 --typetcpdump 选项来解析并分析查询。此方法的精度比较高并且可以捕获所有查询。还可以解析更高级的协议特性比如可以解析二进制协议从而创建并执行服务端预解析的语句prepared statement及压缩协议。另外还有一种方法就是通过 MySQL Proxy 代理层的脚本来记录所有查询但在实践中我们很少这样做。
分析查询日志
不要直接打开整个慢查询日志进行分析这样做只会浪费时间和金钱。首先应该生成一个剖析报告如果需要则可以再查看日志中需要特别关注的部分。自顶向下是比较好的方式否则有可能像前面提到的反而导致业务的逆优化。
从慢查询日志中生成剖析报告需要有一款好工具这里我们建议使用 pt-query-digest 这毫无疑问是分析 MySQL 查询日志最有力的工具。该工具功能强大包括可以将查询报告保存到数据库中以及追踪工作负载随时间的变化。
这里给出一份 pt-query-digest 输出的报告的例子作为进行性能剖析的开始。这是前面提到过的一个未修改过的剖析报告 # Profile# Rank Query ID Response time Calls R/Call V/M Item# # 1 0xBFCF8E3F293F6466 11256.3618 68.1% 78069 0.1442 0.21 SELECT InvitesNew?# 2 0x620B8CAB2B1C76EC 2029.4730 12.3% 14415 0.1408 0.21 SELECT StatusUpdate?# 3 0xB90978440CC11CC7 1345.3445 8.1% 3520 0.3822 0.00 SHOW STATUS# 4 0xCB73D6B5B031B4CF 1341.6432 8.1% 3509 0.3823 0.00 SHOW STATUS# MISC 0xMISC 560.7556 3.4% 23930 0.0234 0.0 17 ITEMS可以看到这个比之前的版本多了一些细节。首先每个查询都有一个 ID这是对查询语句计算出的哈希值指纹计算时去掉了查询条件中的文本值和所有空格并且全部转化为小写字母请注意第三条和第四条语句的摘要看起来一样但哈希指纹是不一样的。该工具对表名也有类似的规范做法。表名 InvitesNew 后面的问号意味着这是一个 分片shard 的表表名后面的分片标识被问号替代这样就可以将同一组分片表作为一个整体做汇总统计。这个例子实际上是来自一个压力很大的分片过的 Facebook 应用。
报告中的 V/M 列提供了方差均值比variance-to-mean ratio的详细数据方差均值比也就是常说的离差指数index of dispersion。离差指数高的查询对应的执行时间的变化较大而这类查询通常都值得去优化。如果 pt-query-digest 指定了 --explain 选项输出结果中会增加一列简要描述查询的执行计划执行计划是查询背后的“极客代码”。通过联合观察执行计划列和V/M列可以更容易识别出性能低下需要优化的查询。
最后在尾部也增加了一行输出显示了其他 17 个占比较低而不值得单独显示的查询的统计数据。可以通过–limit和–outliers选项指定工具显示更多查询的详细信息而不是将一些不重要的查询汇总在最后一行。默认只会打印时间消耗前 10 位的查询或者执行时间超过 1 秒阈值很多倍的查询这两个限制都是可配置的。
剖析报告的后面包含了每种查询的详细报告。可以通过查询的ID或者排名来匹配前面的剖析统计和查询的详细报告。下面是排名第一也就是“最差”的查询的详细报告 查询报告的顶部包含了一些元数据包括查询执行的频率、平均并发度以及该查询性能最差的一次执行在日志文件中的字节偏移值接下来还有一个表格格式的元数据包括诸如标准差一类的统计信息。
接下来的部分是响应时间的直方图。
在细节报告的最后部分是方便复制、粘贴到终端去检查表的模式和状态的语句以及完整的可用于EXPLAIN分析执行计划的语句。
3.3.2 剖析单挑查询
使用 SHOW PROFILE 现已过时
默认是禁用的但可以通过服务器变量在会话连接级别动态地修改。
mysql SET profiling 1;然后在服务器上执行的所有语句都会测量其耗费的时间和其他一些查询执行状态变更相关的数据。这个功能有一定的作用而且最初的设计功能更强大但未来版本中可能会被 Performance Schema 所取代。尽管如此这个工具最有用的作用还是在语句执行期间剖析服务器的具体工作。输出是按照执行顺序排序而不是按花费的时间排序的且无法通过诸如ORDER BY之类的命令重新排序。假如不使用SHOW PROFILE命令而是直接查询INFORMATION_SCHEMA中对应的表则可以按照需要格式化输出 效果好多了通过这个结果可以很容易看到查询时间太长主要是因为花了一大半的时间在将数据复制到临时表这一步。那么优化就要考虑如何改写查询以避免使用临时表或者提升临时表的使用效率。第二个消耗时间最多的是“发送数据Sending data”这个状态代表的原因非常多可能是各种不同的服务器活动包括在关联时搜索匹配的行记录等这部分很难说能优化节省多少消耗的时间。另外也要注意到“结果排序Sorting result”花费的时间占比非常低所以这部分是不值得去优化的。这是一个比较典型的问题所以一般我们都不建议用户在“优化排序缓冲区tuning sort buffer”或者类似的活动上花时间。
使用SHOW STATUS
SHOW STATUS 是一个有用的工具但并不是一款剖析工具。SHOW STATUS的大部分结果都只是一个计数器可以显示某些活动如读索引的频繁程度但无法给出消耗了多少时间。SHOW STATUS的结果中只有一条指的是操作的时间Innodb_row_lock_time而且只能是全局级的所以还是无法测量会话级别的工作。
最有用的计数器包括句柄计数器handler counter、临时文件和表计数器等。
从结果可以看到该查询使用了三个临时表其中两个是磁盘临时表并且有很多的没有用到索引的读操作Handler_read_rnd_next。
使用这个技术的时候要注意SHOW STATUS本身也会创建一个临时表而且也会通过句柄操作访问此临时表这会影响到SHOW STATUS结果中对应的数字而且不同的版本可能行为也不尽相同。
你可能会注意到通过EXPLAIN查看查询的执行计划也可以获得大部分相同的信息但EXPLAIN是通过估计得到的结果而通过计数器则是实际的测量结果。例如EXPLAIN无法告诉你临时表是否是磁盘表这和内存临时表的性能差别是很大的。
3.4 诊断间歇性问题
间歇性的问题比如系统偶尔停顿或者慢查询很难诊断。
为了演示为什么要尽量避免试错的诊断方式下面列举了我们认为已经解决的一些间歇性数据库性能问题的实际案例
应用通过 curl 从一个运行得很慢的外部服务来获取汇率报价的数据。memcached 缓存中的一些重要条目过期导致大量请求落到 MySQL 以重新生成缓存条目。 即 缓存击穿、缓存雪崩。 DNS 查询偶尔会有超时现象。可能是由于互斥锁争用或者内部删除查询缓存的算法效率太低的缘故MySQL 的查询缓存有时候会导致服务有短暂的停顿。当并发度超过某个阈值时InnoDB 的扩展性限制导致查询计划的优化需要很长的时间。
3.4.1 单条查询问题还是服务器问题
如何判断是单条查询问题还是服务器问题呢如果问题不停地周期性出现那么可以在某次活动中观察到或者整夜运行脚本收集数据第二天来分析结果。大多数情况下都可以通过三种技术来解决下面将一一道来。
使用SHOW GLOBAL STATUS
这个方法实际上就是以较高的频率比如一秒执行一次SHOW GLOBAL STATUS命令捕获数据问题出现时则可以通过某些计数器比如Threads_running、Threads_connected、Questions和Queries的“尖刺”或者“凹陷”来发现。这个方法比较简单所有人都可以使用不需要特殊的权限对服务器的影响也很小所以是一个花费时间不多却能很好地了解问题的好方法。 $ mysqladmin ext -i1 | awk /Queries/{q$4-qp;qp$4}/Threads_connected/{tc$4}/Threads_running/{printf %5d %5d %5d\n, q, tc, $4}2147483647 136 7798 136 7767 134 9828 134 7683 134 7784 135 7614 134 7108 134 24187 134 31179 134 281179 134 71151 134 71240 135 71000 135 7这个命令每秒捕获一次SHOW GLOBAL STATUS的数据输出给awk计算并输出每秒的查询数、Threads_connected和Threads_running表示当前正在执行查询的线程数。这三个数据的趋势对于服务器级别偶尔停顿的敏感性很高。一般发生此类问题时根据原因的不同和应用连接数据库方式的不同每秒的查询数一般会下跌而其他两个则至少有一个会出现尖刺。
在实践中有两个原因的可能性比较大。其中之一是服务器内部碰到了某种瓶颈导致新查询在开始执行前因为需要获取老查询正在等待的锁而造成堆积。另外一个常见的原因是服务区突然遇到了大量查询请求的冲击比如前端的memcached 突然失效导致的查询风暴。
这个命令每秒输出一行数据可以运行几个小时或者几天然后将结果绘制成图形这样就可以方便地发现是否有趋势的突变。
使用SHOW PROCESSLIST
这个方法是通过不停地捕获SHOW PROCESSLIST的输出来观察是否有大量线程处于不正常的状态或者有其他不正常的特征。
示例 $ mysql -e SHOW PROCESSLIST\G | grep State: | sort | uniq -c | sort -rn744 State:67 State: Sending data36 State: freeing items8 State: NULL6 State: end4 State: Updating4 State: cleaning up2 State: update1 State: Sorting result1 State: logging slow query大量的线程处于“freeing items”状态是出现了大量有问题查询的很明显的特征和指示。
用这种技术查找问题上面的命令行不是唯一的方法。如果MySQL服务器的版本较新也可以直接查询INFORMATION_SCHEMA中的PROCESSLIST表或者使用innotop工具以较高的频率刷新以观察屏幕上出现的不正常查询堆积。上面演示的这个例子是由于InnoDB内部的争用和脏块刷新所导致但有时候原因可能比这个要简单得多。一个经典的例子是很多查询处于“Locked”状态这是MyISAM的一个典型问题它的表级别锁定在写请求较多时可能迅速导致服务器级别的线程堆积。
使用查询日志
如果因为某些原因不能设置慢查询日志记录所有的查询也可以通过tcpdump和pt-query-digest工具来模拟替代。要注意找到吞吐量突然下降时间段的日志。查询是在完成阶段才写入到慢查询日志的所以堆积会造成大量查询处于完成阶段直到阻塞其他查询的资源占用者释放资源后其他的查询才能执行完成。这种行为特征的一个好处是当遇到吞吐量突然下降时可以归咎于吞吐量下降后完成的第一个查询有时候也不一定是第一个查询。当某些查询被阻塞时其他查询可以不受影响继续运行所以不能完全依赖这个经验。
根据MySQL每秒将当前时间写入日志中的模式统计每秒的查询数量 $ awk /^# Time:/{print$3,$4c;c0}/^# User/{c} slow-query.log080913 21:52:17 51080913 21:52:18 29080913 21:52:19 34080913 21:52:20 33080913 21:52:21 38080913 21:52:22 15080913 21:52:23 47080913 21:52:24 96080913 21:52:25 6080913 21:52:26 66080913 21:52:27 37080913 21:52:28 59理解发现的问题Making sense of the findings
可视化的数据最具有说服力。上面只演示了很少的几个例子但在实际情况中利用上面的工具诊断时可能产生大量的输出结果。可以选择用 gnuplot 或 R或者其他绘图工具将结果绘制成图形。
我们建议诊断问题时先使用前两种方法SHOW STATUS和SHOW PROCESSLIST。这两种方法的开销很低而且可以通过简单的shell脚本或者反复执行的查询来交互式地收集数据。分析慢查询日志则相对要困难一些经常会发现一些蛛丝马迹但仔细去研究时可能又消失了。这样我们很容易会认为其实没有问题。
发现输出的图形异常意味着什么通常来说可能是查询在某个地方排队了或者某种查询的量突然飙升了。接下来的任务就是找出这些原因。
3.4.2 捕获诊断数据
当出现间歇性问题时需要尽可能多地收集所有数据而不只是问题出现时的数据。虽然这样会收集大量的诊断数据但总比真正能够诊断问题的数据没有被收集到的情况要好。
在开始之前需要搞清楚两件事
一个可靠且实时的“触发器”也就是能区分什么时候问题出现的方法。一个收集诊断数据的工具。
诊断触发器
触发器非常重要。这是在问题出现时能够捕获数据的基础。有两个常见的问题可能导致无法达到预期的结果误报false positive或者漏检false negative。误报是指收集了很多诊断数据但期间其实没有发生问题这可能浪费时间而且令人沮丧。而漏检则指在问题出现时没有捕获到数据错失了机会一样地浪费时间。所以在开始收集数据前多花一点时间来确认触发器能够真正地识别问题是划算的。
那么好的触发器的标准是什么呢像关键是找到一些能和正常时的阈值进行比较的指标。通常情况下这是一个计数比如正在运行的线程的数量、处于“freeing items”状态的线程的数量等。
选择一个合适的阈值很重要既要足够高以确保在正常时不会被触发又不能太高要确保问题发生时不会错过。另外要注意要在问题开始时就捕获数据就更不能将阈值设置得太高。
触发条件可以这样设置每秒监控状态值如果Threads_running连续5秒超过20就开始收集诊断数据。
需要收集什么样的数据
答案是尽可能收集所有能收集的数据但只在需要的时间段内收集。包括系统的状态、CPU利用率、磁盘使用率和可用空间、ps的输出采样、内存利用率以及可以从MySQL获得的信息如SHOW STATUS、SHOW PROCESSLIST和SHOW INNODB STATUS。这些在诊断问题时都需要用到可能还会有更多。
执行时间包括用于工作的时间和等待的时间。当一个未知问题发生时一般来说有两种可能服务器需要做大量的工作从而导致大量消耗CPU或者在等待某些资源被释放。所以需要用不同的方法收集诊断数据来确认是何种原因剖析报告用于确认是否有太多工作而等待分析则用于确认是否存在大量等待。如果是未知的问题怎么知道将精力集中在哪个方面呢没有更好的办法所以只能两种数据都尽量收集。
在GNU/Linux平台可用于服务器内部诊断的一个重要工具是oprofile。后面会展示一些例子。也可以使用strace剖析服务器的系统调用但在生产环境中使用它有一定的风险。后面还会继续讨论它。如果要剖析查询可以使用tcpdump。大多数MySQL版本无法方便地打开和关闭慢查询日志此时可以通过监听TCP流量来模拟。另外网络流量在其他一些分析中也非常有用。
对于等待分析常用的方法是GDB的堆栈跟踪。MySQL内的线程如果卡在一个特定的地方很长时间往往都有相同的堆栈跟踪信息。还可以用 pt-pmp 工具来完成这个工作。
pt-collect 用于收集数据一般通过 pt-stalk 来调用。因为涉及很多重要数据的收集所以需要用root权限来运行。默认情况下启动后会收集30秒的数据然后退出。对于大多数问题的诊断来说这已经足够但如果有误报false positive的问题出现则可能收集的信息就不够。这个工具很容易下载到并且不需要任何配置配置都是通过pt-stalk进行的。系统中最好安装gdb和oprofile然后在pt-stalk中配置使用。另外mysqld也需要有调试[符号信息]。当触发条件满足时pt-collect会很好地收集完整的数据。它也会在目录中创建时间戳文件。
解释结果数据
如果已经正确地设置好触发条件并且长时间运行pt-stalk则只需要等待足够长的时间来捕获几次问题就能够得到大量的数据来进行筛选。从哪里开始最好呢我们建议先根据两个目的来查看一些东西。第一检查问题是否真的发生了因为有很多的样本数据需要检查如果是误报就会白白浪费大量的时间。第二是否有非常明显的跳跃性变化。 在服务器正常运行时捕获一些样本数据也很重要而不只是在有问题时捕获数据。这样可以帮助对比确认是否某些样本或者样本中的某部分数据有异常。例如在查看进程列表process list中查询的状态时可以回答一些诸如“大量查询处于正在排序结果的状态是不是正常的”的问题。 查看异常的查询或事务的行为以及异常的服务器内部行为通常都是最有收获的。查询或事务的行为可以显示是否是由于使用服务器的方式导致的问题性能低下的SQL查询、使用不当的索引、设计糟糕的数据库逻辑架构等。通过抓取TCP流量或者SHOW PROCESSLIST输出可以获得查询和事务出现的地方从而知道用户对数据库进行了什么操作。通过服务器的内部行为则可以清楚服务器是否有bug或者内部的性能和扩展性是否有问题。这些信息在类似的地方都可以看到包括在oprofile或者gdb的输出中但要理解则需要更多的经验。
如果遇到无法解释的错误则最好将收集到的所有数据打包提交给技术支持人员进行分析。MySQL的技术支持专家应该能够从数据中分析出原因详细的数据对于支持人员来说非常重要。另外也可以将Percona Toolkit中另外两款工具pt-mysql-summary和pt-summary的输出结果打包这两个工具会输出MySQL的状态和配置信息以及操作系统和硬件的信息。
Percona Toolkit还提供了一款快速检查收集到的样本数据的工具pt-sift。这个工具会轮流导航到所有的样本数据得到每个样本的汇总信息。如果需要也可以钻取到详细信息。使用此工具至少可以少打很多字少敲很多次键盘。
另外一个重要的关于等待分析的性能瓶颈分析工具是gdb的堆栈跟踪。堆栈需要自下而上来看。要真正地发挥堆栈跟踪的价值需要将很多的信息聚合在一起来看。这种技术是由Domas Mituzas推广的他以前是MySQL的支持工程师开发了著名的穷人剖析器“poor man’s profiler”。他目前在Facebook工作和其他人一起开发了更多的收集和分析堆栈跟踪的工具。可以从他的这个网站发现更多的信息http://www.poormansprofiler.org。
在Percona Toolkit中我们也开发了一个类似的穷人剖析器叫做 pt-pmp 。这是一个用shell和awk脚本编写的工具可以将类似的堆栈跟踪输出合并到一起然后通过sort|uniq|sort将最常见的条目在最前面输出。
3.5 其他剖析工具
3.5.1 使用 USER_STATISTICS 表
有几个要点要说明一下
可以查找使用得最多或者使用得最少的表和索引通过读取次数或者更新次数或者两者一起排序。可以查找出从未使用的索引可以考虑删除之。可以看看复制用户的CONNECTED_TIME和BUSY_TIME以确认复制是否会很难跟上主库的进度。
在MySQL 5.6中Performance Schema中也添加了很多类似上面这些功能的表。
3.5.2 使用 strace
strace工具可以调查系统调用的情况。有好几种可以使用的方法其中一种是计算系统调用的时间并打印出来
这种用法和oprofile有点像。但是oprofile还可以剖析程序的内部符号而不仅仅是系统调用。另外strace拦截系统调用使用的是不同于oprofile的技术这会有一些不可预期性开销也更大些。strace度量时使用的是实际时间而oprofile使用的是花费的CPU周期。举个例子当I/O等待出现问题的时候strace能将它们显示出来因为它从诸如read或者pread64这样的系统调用开始计时直到调用结束。但oprofile不会这样因为I/O系统调用并不会真正地消耗CPU周期而只是等待I/O完成而已。
我们会在需要的时候使用oprofile因为strace对像mysqld这样有大量线程的场景会产生一些副作用。当strace附加上去后mysqld的运行会变得很慢因此不适合在产品环境中使用。但在某些场景中strace还是相当有用的Percona Toolkit中有一个叫做pt-ioprofile的工具就是使用strace来生成I/O活动的剖析报告的。这个工具很有帮助可以证明或者驳斥某些难以测量的情况下的一些观点此时其他方法很难达到目的如果运行的是MySQL 5.6使用Performance Schema也可以达到目的。
