13518219792
一个诊断案例（ ）
我们提供的服务有：网站设计制作、成都网站制作、微信公众号开发、网站优化、网站认证、柳南ssl等。为上1000家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的柳南网站制作公司
我们看到了两种可能性 要么是数据库导致了I/O（如果能找到源头的话 那么可能就找到了问题的原因） 要么不是数据库导致了所有的I/O 而是其他什么导致的 而系统因为缺少I/O 资源影响了数据库性能 我们也很小心地尽力避免引入另外一个隐式的假设 磁盘很忙并不一定意味着MySQL 会有问题 要记住 这个服务器主要的压力是内存读取 所以也很可能出现磁盘长时间无法响应但没有造成严重问题的现象
如果你一直跟随我们的推理逻辑 就可以发现还需要回头检查一下另外一个假设 我们已经知道磁盘设备很忙 因为其等待时间很高 对于固态硬盘来说 其I/O 平均等待时间一般不会超过 / 秒 实际上 从iostat 的输出结果也可以发现磁盘本身的响应还是很快的 但请求在块设备队列中等待很长的时间才能进入到磁盘设备 但要记住 这只是iostat 的输出结果 也可能是错误的信息
究竟是什么导致了性能低下？
当一个资源变得效率低下时 应该了解一下为什么会这样 有如下可能的原因
资源被过度使用 余量已经不足以正常工作
资源没有被正确配置
资源已经损坏或者失灵
回到上面的例子中 iostat 的输出显示可能是磁盘的工作负载太大 也可能是配置不正确（在磁盘响应很快的情况下 为什么I/O 请求需要排队这么长时间才能进入到磁盘？） 然而 比较系统的需求和现有容量对于确定问题在哪里是很重要的一部分 大量的基准测试证明这个客户使用的这种SSD 是无法支撑几百MB/s 的写操作的 所以 尽管iostat 的结果表明磁盘的响应是正常的 也不一定是完全正确的 在这个案例中 我们没有办法证明磁盘的响应比iostat 的结果中所说的要慢 但这种情况还是有可能的 所以这不能改变我们的看法 可能是磁盘被滥用注 或者是错误的配置 或者两者兼而有之 是性能低下的罪魁祸首
在检查过所有诊断数据之后 接下来的任务就很明显了 测量出什么导致了I/O 消耗 不幸的是 客户当前使用的GNU/Linux 版本对此的支持不力 通过一些工作我们可以做一些相对准确的猜测 但首先还是需要探索一下其他的可能性 我们可以测量有多少I/O来自MySQL 但客户使用的MySQL 版本较低以致缺乏一些诊断功能 所以也无法提供确切有利的支持
作为替代 基于我们已经知道MySQL 如何使用磁盘 我们来观察MySQL 的I/O 情况 通常来说 MySQL 只会写数据 日志 排序文件和临时表到磁盘 从前面的状态计数器和其他信息来看 首先可以排除数据和日志的写入问题 那么 只能假设MySQL 突然写入大量数据到临时表或者排序文件 如何来观察这种情况呢？有两个简单的方法 一是观察磁盘的可用空间 二是通过lsof 命令观察服务器打开的文件句柄 这两个方法我们都采用了 结果也足以满足我们的需求 下面是问题期间每秒运行df–h 的结果
下面则是lsof 的数据 因为某些原因我们每五秒才收集一次 我们简单地将mysqld 在/tmp 中打开的文件大小做了加总 并且把总大小和采样时的时间戳一起输出到结果文件中
$ awk
/mysqld *tmp/ {
total += $ ;
}
/^Sun Mar / total {
printf %s % f MB\n $ total/ / ;
total = ;
} lsof txt
: : MB
: : MB
: : MB
: : MB
: : MB
从这个数据可以看出 在问题之初MySQL 大约写了 GB 的数据到临时表 这和之前在SHOW PROCESSLIST 中有大量的 Copying to tmp table 相吻合 这个证据表明可能是某些效率低下的查询风暴耗尽了磁盘资源 根据我们的工作直觉 出现这种情况比较普遍的一个原因是缓存失效 当memcached 中所有缓存的条目同时失效 而又有很多应用需要同时访问的时候 就会出现这种情况 我们给开发人员出示了部分采样到的查询 并讨论这些查询的作用 实际情况是 缓存同时失效就是罪魁祸首（这验证了我们的直觉） 一方面开发人员在应用层面解决缓存失效的问题 另一方面我们也修改了查询 避免使用磁盘临时表 这两个方法的任何一个都可以解决问题 当然最好是两个都实施
返回目录 高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
lishixinzhi/Article/program/MySQL/201311/29695
看过高性能mysql，对于想深入了解mysql性能优化的人来说绝对值得一看
在MySQL社区，这是一本重量级的书，我不知道出版社是怎么挑选译者的，但是很明显，我个人的意见，这次挑选非常的失败。书中98页倒数第4行的"binary search"的翻译（二进制搜索）已经道出了一切，但凡学过计算机的，我估计都不能做出这样的翻译。在计算机领域，二进制是一个专门的术语，有特定的含义。我不仅怀疑译者根本没学过"binary search"算法，以至于只能按字面翻译，我甚至怀疑他们连“二进制”的含义可能也不懂，找这样的人来翻译，真是天大的笑话。 再举一个术语的翻译“secondary index”，书中的译法是“第二索引”，暂且不论惯用的“二级索引”是否是一个标准的译法，假如在主键之外，还有B，C两个索引，如果B叫“第二索引”，那么C就应该叫“第三索引”了？为什么C也叫“第二”呢，难道是并列第二？“第二”在汉语中是一个意思很明确的词，你当然可以说“第二”也能表示“二级”的意思，这种牵强的脱离通用语义的翻译真是对翻译标准“信雅达”中“达”字的讽刺。 关于“达”我们还可以找一个例子，介绍coverring index的部分，译文第96页，原文第124页。原文是“For example,the sakila.actor table uses InnoDB and has an index on last_name, so the index can cover queries that retrieve the primary key column actor_id, even though that column isn’t technically part of the index”，译文是“例如，sakila.actor表适用了InnoDB并且在last_name上有索引，因此，即使该列不是索引的一部分，索引页可以覆盖取得主键actor_id的查询”，原文读来没有任何的歧义，译文却变了样，第一遍读的时候，你能分辨出“即使该列不是索引的一部分”中的“该列”是指代的“last_name"呢？还是后面出现的"actor_id”呢？将代词放在指代的名词之前出现，这绝对是对人的智力的挑战，即便是诗歌，我也没见汉语中有多少这样的用法，遑论技术性文字。在原文中"that column"这个代词出现在了"actor_id"之后，不知道为什么在译文中，代词就钻到了指代的名词之前。 如果可以抛开“达”，还要争辩词的译法是“见仁见智”的，那么对“信”的违背则已经使这本重量级巨著的翻译失去了最基本的存在价值，随便举两个例子： 1. 4.6查询提示优化对HIGH_PRIORITY的描述，译本第152页，原书第195页，原文是“HIGH_PRIORITY tells MySQL to schedule a SELECT statement before other statements that may be waiting for locks, so they can modify data.”，译文是“HIGH_PRIORITY告诉MySQL将SELECT语句放在其他语句的前面，以便它修改数据”，原文中的“so they can modify data"变成了"以便它可以修改数据"，复数形式的they变成了单数形式的"它"，这个改变虽然细微，但直接影响了这个位置的代词所指代的主语，这个代词到底是"SELECT statement"呢？还是"other statements that may be waiting for locks"？原文中当然是其他能modify data的statements，而到了疑问中，变成了"SELECT statement"，问一个菜鸟级的问题，select statement能modify data吗？ 2. 还是4.6查询提示优化，对DELAYED的描述，译文第152页，原文第196页。原文是"It lets the statement to which it is applied return immediately and places the inserted rows into a buffer, which will be inserted in bulk when the table is free"，译文是"应用了这个提示的语句会立即返回并将待插入的列放入缓冲区，在表空闲的时候再执行插入"，粗看没什么问题，细看问题一大堆。 2.1 在原文中，主语是it，指代的是"DELAYED"这个hint，到了译文中，主语从"提示"本身变成了"应用了这个提示的语句"，于是在原文中的"delayed"这个hint一方面使语句立即返回，另一方面使MySQL在后台处理被缓存的数据两层意思变成了语句一方面返回，另一方面“将待插入的列放入缓冲区”，到底是"DELAYED"使数据被插入buffer，还是应用了"DELAYED"的语句使数据被插入了buffer，区别虽然微妙，但区别就是区别，译文的意思与原文已差之毫厘，谬以千里。 2.2 原文中"which will be inserted in bulk..."是一个被动语态，指数据被插入，主语没有明确指出，在上下文环境中当然是数据库；而到了译文中，“在表空闲的时候再执行插入”是一个主动的语态，“谁”执行了插入？如果和上句连起来，很容易理解成“应用了这个提示的语句在表空闲的时候再执行插入”，这不是扯淡吗？当然，稍微有点数据库常识的人都不会这样理解，但原文原本语义清晰，翻译过来却主语混乱，实在令人难以接受。 2.2 在原文中的"rows"，一个复数形式的词，到了译文中，变成了"列"，假如说复数变单数还能接受，把"row"翻译成"列"真是天才的创举。 2.3 原文中"will be inserted in bulk when ..."明确指出了insert的方式是"in bulk"，但是这个信息在译文中丢失了。 类似的问题简直处处可见，原文的文字简洁清晰，非常容易理解，但我读到的译文却非常难以理解，更可恨的是，原文中大量的信息被扭曲，抛弃。“信雅达”这三标准没有一个做到。我个人的总结是，这个译本的水平跟中国足球的水平一样，能把球停在百米开外，一个字，糙。 客观地说，这本书至少将MySQL优化的知识在中国的传播门槛大大降低，但咱不是黄莺，不会唱赞歌，既然是书评，就是要来挑刺的，看不到刺，容不得刺，电子工业永远没有赶上O'Relly的机会，中国的技术书籍永远都只能是菜鸟水平。
mysql数据库的优点如下：
1、速度:运行速度快。
2、价格:MySQL对多数个人来说是免费的。
3、容易使用;与其他大型数据库的设置和管理相比，其复杂程度较低，容易学习。
4、可移植性:能够工作在众多不同的系统平台上，例如:Windows、Linux、Unix、MacOS等。
5、丰富的接口:提供了用于C、C++、Eiffel、Java、Perl、PHP、Python、Rudy和TCL等语言的APl。6、支持查询语言:MySQL可以利用标准SQL语法和支持ODBC(开放式数据库连接）的应用程序。
7、安全性和连接性;十分灵活和安全的权限和密码系统，允许主机验证。连接到服务器时，所有的密码均采用加密形式，从而保证了密码安全。并且由于MySQL时网络化的，因此可以在因特网网上的任何地方访问，提高数据共享效率。
运行基准测试并分析结果
一旦准备就绪 就可以着手基准测试 收集和分析数据了
通常来说 自动化基准测试是个好主意 这样做可以获得更精确的测试结果 因为自动化的过程可以防止测试人员偶尔遗漏某些步骤 或者误操作 另外也有助于归档整个测试过程
自动化的方式有很多 可以是一个Makefile 文件或者一组脚本 脚本语言可以根据需要选择 shell PHP Perl 等都可以 要尽可能地使所有测试过程都自动化 包括装载数据 系统预热 执行测试 记录结果等
一旦设置了正确的自动化操作 基准测试将成为一步式操作 如果只是针对某些应用做一次性的快速验证测试 可能就没必要做自动化 但只要未来可能会引用到测试结果 建议都尽量地自动化 否则到时候可能就搞不清楚是如何获得这个结果的 也不记得采用了什么参数 这样就很难再通过测试重现结果了
基准测试通常需要运行多次 具体需要运行多少次要看对结果的记分方式 以及测试的重要程度 要提高测试的准确度 就需要多运行几次 一般在测试的实践中 可以取最好的结果值 或者所有结果的平均值 亦或从五个测试结果里取最好三个值的平均值 可以根据需要更进一步精确化测试结果 还可以对结果使用统计方法 确定置信区间（confidence interval）等 不过通常来说 不会用到这种程度的确定性结果注 只要测试的结果能满足目前的需求 简单地运行几轮测试 看看结果的变化就可以了 如果结果变化很大 可以再多运行几次 或者运行更长的时间 这样都可以获得更确定的结果
获得测试结果后 还需要对结果进行分析 也就是说 要把 数字 变成 知识 最终的目的是回答在设计测试时的问题 理想情况下 可以获得诸如 升级到 核CPU 可以在保持响应时间不变的情况下获得超过 % 的吞吐量增长 或者 增加索引可以使查询更快 的结论 如果需要更加科学化 建议在测试前读读null hypothesis 一书 但大部分情况下不会要求做这么严格的基准测试
如何从数据中抽象出有意义的结果 依赖于如何收集数据 通常需要写一些脚本来分析数据 这不仅能减轻分析的工作量 而且和自动化基准测试一样可以重复运行 并易于文档化 下面是一个非常简单的shell 脚本 演示了如何从前面的数据采集脚本采集到的数据中抽取时间维度信息 脚本的输入参数是采集到的数据文件的名字
假设该脚本名为 *** yze 当前面的脚本生成状态文件以后 就可以运行该脚本 可能会得到如下的结果
第一行是列的名字 第二行的数据应该忽略 因为这是测试实际启动前的数据 接下来的行包含Unix 时间戳 日期 时间（注意时间数据是每 秒更新一次 前面脚本说明时曾提过） 系统负载 数据库的QPS（每秒查询次数）五列 这应该是用于分析系统性能的最少数据需求了 接下来将演示如何根据这些数据快速地绘成图形 并分析基准测试过程中发生了什么
返回目录 高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
lishixinzhi/Article/program/MySQL/201311/29735
