高性能MySQL：捕获诊断数据（1）[1]

捕获诊断数据（）

当出现间歇性问题时需要尽可能多地收集所有数据而不只是问题出现时的数据虽然这样会收集大量的诊断数据但总比真正能够诊断问题的数据没有被收集到的情况要好

在开始之前需要搞清楚两件事

一个可靠且实时的触发器也就是能区分什么时候问题出现的方法

一个收集诊断数据的工具

诊断触发器

触发器非常重要这是在问题出现时能够捕获数据的基础有两个常见的问题可能导致无法达到预期的结果误报（false positives）或者漏检（false negatives）误报是指收集了很多诊断数据但期间其实没有发生问题这可能浪费时间而且令人沮丧而漏检则指在问题出现时没有捕获到数据错失了机会一样地浪费时间所以在开始收集数据前多花一点时间来确认触发器能够真正地识别问题是划算的

那么好的触发器的标准是什么呢？像前面的例子展示的Threads_running 的趋势在出现问题时会比较敏感而没有问题时则比较平稳另外SHOW PROCESSLIST 中线程的异常状态尖峰也是个不错的指标当然除此之外还有很多的方法包括SHOW INNODB STATUS的特定输出服务器的平均负载尖峰等关键是找到一些能和正常时的阈值进行比较的指标通常情况下这是一个计数比如正在运行的线程的数量处于freeing items状态的线程的数量等当要计算线程某个状态的数量时grep 的c 选项非常有用

$ mysql e SHOW PROCESSLIST\G | grep c State: freeing items

选择一个合适的阈值很重要既要足够高以确保在正常时不会被触发又不能太高要确保问题发生时不会错过另外要注意要在问题开始时就捕获数据就更不能将阈值设置得太高问题持续上升的趋势一般会导致更多的问题发生如果在问题导致系统快要崩溃时才开始捕获数据就很难诊断到最初的根本原因如果可能在问题还是涓涓细流的时候就要开始收集数据而不要等到波涛汹涌才开始举个例子Threads_connected 偶尔出现非常高的尖峰值在几分钟时间内会从 沖到 或者更高所以设置阈值为 也可以捕获到问题但为什么非要等到这么高的时候才收集数据呢？如果在正常时该值一般不超过将阈值设置为 或者 会更好

回到前面关于Threads_running 的例子正常情况下的并发度不超过但是阈值设置为 并不是一个好注意很可能会导致很多误报即使设置为 也不够可能还是会有很多正常的波动会到这个范围当并发运行线程到 的时候可能也会有少量堆积的情况但可能还没到问题的引爆点但也应该在糟糕到一眼就能看出问题前就清晰地识别出来对于这个例子我们建议阀值可以设置为

我们当然希望在问题确实发生时能捕获到数据但有时候也需要稍微等待一下以确保不是误报或者短暂的尖峰所以最后的触发条件可以这样设置每秒监控状态值如果Threads_running 连续 秒超过就开始收集诊断数据（顺便说一句我们的例子中问题只持续了 秒就消失了这是为了使例子简单而设置的 秒的故障不容易诊断而我们碰到过的大部分问题持续时间都会更长一些）

所以我们需要利用一种工具来监控服务器当达到触发条件时能收集数据当然可以自己编写脚本来实现不过不用那么麻烦Percona Toolkit 中的ptstalk 就是为这种情况设计的这个工具有很多有用的特性只要碰到过类似问题就会明白这些特性的必要性例如它会监控磁盘的可用空间所以不会因为收集太多的数据将空间耗尽而导致服务器崩溃如果之前碰到过这样的情况你就会理解这一点了

ptstalk 的用法很简单可以配置需要监控的变量阈值检查的频率等还支持一些比实际需要更多的花哨特性但在这个例子中有这些已经足够了在使用之前建议先阅读附带的文档ptstalk 还依赖于另外一个工具执行真正的收集工作接下来会讨论

[] []