一个诊断案例（ ）
这里大多数符号（symbol）代表的意义并不是那么明显 而大部分的时间都消耗在内核符号（no vmlinux）和一个通用的mysqld符号中 这两个符号无法告诉我们更多的细节 不要被多个ha_innodb so符号分散了注意力 看一下他们占用的百分比就知道了 不管它们在做什么 其占用的时间都很少 所以应该不会是问题所在 这个例子说明 仅仅从剖析报表出发是无法得到解决问题的结果的 我们追踪的数据是错误的 如果遇到上述例子这样的情况 需要继续检查其他的数据 寻找问题根源更明显的证据
到这里 如果希望从gdb的堆栈跟踪进行等待分析 请参考 节的最后部分内容 那个案例就是我们当前正在诊断的这个问题 回想一下 当时的堆栈跟踪分析的结果是正在等待进入到InnoDB内核 所以SHOW INNODB STATUS的输出结果中有 queries inside InnoDB queries in queue
从上面的分析发现问题的关键点了吗？没有 我们看到了许多不同问题可能的症状 根据经验和直觉可以推测至少有两个可能的原因 但也有一些没有意义的地方 如果再次检查一下iostat的输出 可以发现wsec/s列显示了至少在 秒内 服务器每秒写入了几百MB的数据到磁盘 每个磁盘扇区是 B 所以这里采样的结果显示每秒最多写入了 MB的数据 然后整个数据库也只有 MB大小 系统的压力又主要是SELECT查询 怎么会出现这样的情况呢？
对一个系统进行检查的时候 应该先问一下自己 是否也碰到过上面这种明显不合理的问题 如果有就需要深入调查 应该尽量跟进每一个可能的问题直到发现结果 而不要被离题太多的各种情况分散了注意力 以致最后都忘记了最初要调查的问题 可以把问题写在小纸条上 检查一个划掉一个 最后再确认一遍所有的问题都已经完成调查
在这一点上 我们可以直接得到一个结论 但却可能是错误的 可以看到主线程的状态是InnoDB 正在刷新脏页 在状态输出中出现这样的情况 一般都意味着刷新已经延迟了 我们知道这个版本的InnoDB 存在 疯狂刷新 的问题（或者也被称为检查点停顿） 发生这样的情况是因为InnoDB 没有按时间均匀分布刷新请求 而是隔一段时间突然请求一次强制检查点导致大量刷新操作 这种机制可能会导致InnoDB 内部发生严重的阻塞 导致所有的操作需要排队等待进入内核 从而引发InnoDB 上一层的服务器产生堆积 在第 章中演示的例子就是一个因为 疯狂刷新 而导致性能周期性下跌的问题 很多类似的问题都是由于强制检查点导致的 但在这个案例中却不是这个问题 有很多方法可以证明 最简单的方法是查看SHOW STATUS 的计数器 追踪一下Innodb_buffer_pool_pages_flushed 的变化 之前已经提到了 这个值并没有怎么增加 另外 注意到InnoDB 缓冲池中也没有大量的脏页需要刷新 肯定不到几百MB 这并不值得惊讶 因为这个服务器的工作压力几乎都是SELECT 查询 所以可以得到一个初步的结论 我们要关注的不是InnoDB 刷新的问题 而应该是刷新延迟的问题 但这只是一个现象 而不是原因 根本的原因是磁盘的I/O 已经饱和 InnoDB 无法完成其I/O 操作 至此我们消除了一个可能的原因 可以从基于直觉的原因列表中将其划掉了
从结果中将原因区别出来有时候会很困难 当一个问题看起来很眼熟的时候 也可以跳过调查阶段直接诊断 当然最好不要走这样的捷径 但有时候依靠直觉也非常重要 如果有什么地方看起来很眼熟 明智的做法还是需要花一点时间去测量一下其充分必要条件 以证明其是否就是问题所在 这样可以节省大量时间 避免查看大量其他的系统和性能数据 不过也不要过于相信直觉而直接下结论 不要说 我之前见过这样的问题 肯定就是同样的问题 而是应该去收集相关的证据 尤其是能证明直觉的证据
下一步是尝试找出是什么导致了服务器的I/O 利用率异常的高 首先应该注意到前面已经提到过的 服务器有连续几秒内每秒写入了几百MB 数据到磁盘 而数据库一共只有 MB 大小 怎么会发生这样的情况？ 注意到这里已经隐式地假设是数据库导致了磁盘写入 那么有什么证据表明是数据库导致的呢？当你有未经证实的想法 或者觉得不可思议时 如果可能的话应该去进行测量 然后排除掉一些怀疑
返回目录 高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
lishixinzhi/Article/program/MySQL/201311/29696