一个诊断案例（）
在本节中我们将逐步演示一个客户实际碰到的间歇性性能问题的诊断过程这个案例的诊断需要具备MySQLInnoDB 和GNU/Linux 的相关知识但这不是我们要讨论的重点要尝试从疯狂中找到条理阅读本节并保持对之前的假设和猜测的关注保持对之前基于合理性和基于可度量的方式的关注等等我们在这里深入研究一个具体和详细的案例为的是找到一个简单的一般性的方法
在尝试解决其他人提出的问题之前先要明确两件事情并且最好能够记录下来以免遗漏或者遗忘
首先问题是什么？一定要清晰地描述出来费力去解决一个错误的问题是常有的事在这个案例中用户抱怨说每隔一两天服务器就会拒绝连接报max_connections 错误这种情况一般会持续几秒到几分钟发生的时间非常随机
其次为解决问题已经做过什么操作？在这个案例中用户没有为这个问题做过任何操作这个信息非常有帮助因为很少有其他事情会像另外一个人来描述一件事情发生的确切顺序和曾做过的改变及其后果一样难以理解（尤其是他们还是在经过几个不眠之夜后满嘴咖啡味道地在电话里绝望吶喊的时候）如果一台服务器遭受过未知的变更产生了未知的结果问题就更难解决了尤其是时间又非常有限的时候
搞清楚这两个问题后就可以开始了不仅需要去了解服务器的行为也需要花点时间去梳理一下服务器的状态参数配置以及软硬件环境使用ptsummary 和ptmysqlsummary 工具可以获得这些信息简单地说这个例子中的服务器有 个CPU 核心GB 内存数据量有MB且全部采用InnoDB 引擎存储在一块SSD 固态硬盘上服务器的操作系统是GNU/LinuxMySQL 版本使用的存储引擎版本是InnoDBplugin 之前我们已经为这个客户解决过一些异常问题所以对其系统已经比较了解过去数据库从来没有出过问题大多数问题都是由于应用程序的不良行为导致的初步检查了服务器也没有发现明显的问题查询有一些优化的空间但大多数情况下响应时间都不到 毫秒所以我们认为正常情况下数据库服务器运行良好（这一点比较重要因为很多问题一开始只是零星地出现慢慢地累积成大问题比如RAID 阵列中坏了一块硬盘这种情况）
这个案例研究可能有点乏味这里我们不厌其烦地展示所有的诊断数据解释所有的细节对几个不同的可能性深入进去追查原因在实际工作中其实不会对每个问题都采用这样缓慢而冗长的方式也不推荐大家这样做这里只是为了更好地演示案例而已
我们安装好诊断工具在Threads_connected 上设置触发条件正常情况下Threads_connected 的值一般都少于但在发生问题时该值可能飙升到几百下面我们会先给出一个样本数据的收集结果后续再来评论首先试试看你能否从大量的输出中找出问题的重点在哪里
vmstar的输出也验证了iostat的结果并且CPU的大部分时间是空闲的只是偶尔在写尖峰时有一些I/O等待时间（最高约占%的CPU）是不是感觉脑袋里塞满了东西？当你深入一个系统的细节并且没有任何先入为主（或者故意忽略了）的观念时很容易碰到这种情况最终只能检查所有可能的情况很多被检查的地方最终要么是完全正常的要么发现是问题导致的结果而不是问题产生的原因尽管此时我们会有很多关于问题原因的猜测但还是需要继续检查下面给出的oprofile报表并且在给出更多数据的时候添加一些评论和解释
samples % image name app name symbol name
novmlinux novmlinux /novmlinux
mysqld mysqld /usr/libexec/mysqld
libcso libcso memcpy
ha_innodbso ha_innodbso build_template（）
ha_innodbso ha_innodbso btr_search_guess_on_hash
ha_innodbso ha_innodbso row_sel_store_mysql_rec
ha_innodbso ha_innodbso rec_init_offsets_comp_ordinary
ha_innodbso ha_innodbso row_search_for_mysql
ha_innodbso ha_innodbso rec_get_offsets_func
ha_innodbso ha_innodbso cmp_dtuple_rec_with_match
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
