MySQL间歇慢速查询

Question

在最近将MySQL 5.1迁移到一台新的、速度更快的服务器之后，我看到了一些查询运行缓慢的偶然和看似随机的时期。尽管进行了大量的调查，我还是找不到问题的根源。

在这篇文章的结尾，我列举了几个具体的问题，但除此之外，我不知道现在该去哪里。如果您能提出任何可能的解决方案或我可以使用的工具，我将非常感谢。

症状和背景

每隔一两天，一小群查询将随机出现在我的慢速查询日志中，通常在两三分钟内出现。这些查询通常在30-60毫秒内执行，花费的时间要长得多--在6到20秒之间。慢速查询日志并不表示这些查询的任何锁定时间。

迁移到新的数据库服务器后，问题变得很明显。这两台服务器都在MySQL 6下运行CentOS 5.1，并且都使用SSD进行数据库存储。与旧服务器不同，新服务器使用Linux软件RAID-1运行两个SSD。虽然硬件已经发生了变化(不同的数据中心，不同的网络)，但是软件没有改变，迁移时的CentOS版本和应用程序版本是一样的。应用程序代码也保持不变。

我的分析/故障排除

• 我没有理由相信查询本身是有问题的，或者数据库正在经历性能问题；这些查询并不复杂，也不是未经优化的查询。它们通常在<100 has中执行，并且数据库服务器的典型负载平均小于1.0。
• 我不认为在这些缓慢的时期，所有的查询都会受到影响。服务器平均每小时看到大约8000次查询。但是我的慢速查询日志在慢速期间只显示了几个(可能是5-10)。
• 这些查询似乎没有共同之处。它们大多是针对几个不同数据库的select语句，这些数据库涉及同时使用InnoDB和MyISAM引擎的表。有时也会出现更新查询。
• 我尝试将缓慢的查询时间减少到2秒(从5秒)，以确定是否有更多的缓慢周期导致非常长时间运行的查询。我不认为会发生这种事。缓慢的时期似乎开始和停止突然和莫名其妙。
• 由于怀疑IO是个问题，我设置sar实用程序来每分钟捕获系统统计数据。我无法发现慢化周期与sar报告的系统或IO负载之间的相关性。记录慢速查询时，服务器似乎几乎处于空闲状态。
• 我检查了/var/log中的所有cron作业以及所有日志文件，但没有发现在缓慢的同时发生任何有趣的事情。
• 为了安全起见，我禁用了r1soft (备份软件)和其他与备份相关的任务.我还降低了狮身人面像的IO优先级，这是一个运行在同一台服务器上的搜索引擎。两者都没有任何效果。
• 我试图禁用查询缓存，因为我已经看到它会导致奇怪的锁定情况。没有效果。
• 我将MySQL升级到5.5版，只是为了看看会发生什么。这也对缓慢的查询问题没有影响。

问题

1. 有没有办法找出新服务器是否有什么奇怪的、断断续续的硬件问题？正如我上面所写的，在仔细检查系统日志时，我没有注意到任何事情。
2. 网络延迟或数据包丢失是否有可能在其中起作用？我不这么认为，因为慢速查询日志中记录的查询时间应该排除任何网络延迟，对吗？
3. 我看到MySQL 5.5提供了对我来说是新的性能模式特性。但我不太清楚这是怎么用的。有什么办法可以用这个来解决这个问题吗？

非常感谢在这个令人沮丧的问题上的任何帮助！

Answer 1

简短解决方案:问题与IO有关。这是通过转移到一个新的，更现代化的系统，更快的SSDs.

来解决的。

较长版本：

我花了很多时间花了几个月的时间，试图弄清上面描述的性能问题。作为权宜之计，我尽一切可能防止并发查询导致大量IO (例如备份和搜索引擎索引)。然而，这并没有真正解决问题，也没有回答我发布的问题--它只是用一个IO密集型的进程阻塞数据库活动来掩盖潜在的问题。

我的“答案”，如果你可以这么说的话，最终是通过转向更现代的硬件来实现的。与使用消费者级美光SSDs的旧系统不同，新服务器使用IBM数据中心SSDs和更快的处理器。否则，软件配置与上面测试的系统相同(相同的操作系统、相同的MySQL用例、相同的mdraid 1配置，等等)。

我只能假设新系统的更好的SSD和/或更现代的主板和芯片组更好地处理并发操作。无论数据库服务器发生了什么情况，我都不再经历任何类型的缓慢查询。数据库操作似乎不像以前那样受到磁盘活动的影响。

因此，如果您正在经历奇怪的数据库查询减速，并且找不到任何应用程序级的原因，请不要忘记将底层硬件视为可能的源。尝试从不同的主机提供商租用一个月的新专用服务器或VPS，复制您的软件配置，并尝试一下。为我工作！