一个诊断案例（）
这里大多数符号（symbol）代表的意义并不是那么明显而大部分的时间都消耗在内核符号（novmlinux）和一个通用的mysqld符号中这两个符号无法告诉我们更多的细节不要被多个ha_innodbso符号分散了注意力看一下他们占用的百分比就知道了不管它们在做什么其占用的时间都很少所以应该不会是问题所在这个例子说明仅仅从剖析报表出发是无法得到解决问题的结果的我们追蹤的数据是错误的如果遇到上述例子这样的情况需要继续检查其他的数据寻找问题根源更明显的证据
到这里如果希望从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开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
