我在最近几天遇到了一个问题，我有一个数据库服务器2个四核处理器和24 GB的内存，最近我们遇到了一个大问题，服务器正常运行在大约130％的CPU，然后它会随机高峰到几乎750％的内核都能够让我们的网站超级爬行。 我重新启动了mysql进程，然后解决了大约10分钟后再次发生。 最后一次发生，我让它坐在750％，几分钟后它又回落。 我做了一个stream程转储，因为它正在发生，它有大约4000个队列中的查询，说复制/发送到tmp表。
如果有人知道这个问题，或者在MySQL innodb数据库和PHP的专家让我知道，我甚至愿意支付以获得此修复，价格不是一个问题，只是想解决问题。
不要像这样重启MySQL。 通常根本没有帮助 – 麻烦的查询或情况迟早会回来，在重新启动MySQL之后需要热身。 重新启动将刷新它的caching等等。
我怀疑的是，在你的网站上有某种exception活动（比如DoS攻击或者Slashdot / Reddit效果），或者最近的一个更新包含了一个新的数据库查杀错误。 检查您的http日志，或更多的视觉前景，通过Webalizer或类似的程序运行Apache日志。
如果您的问题不是由于networking活动造成的，或者您希望在将来避免这样的问题，那么您刚才描述的棘手的典型情况就是：
未经最佳调整的my.cnf – 您是否对InnoDB设置进行了微调？ 我们可以看看你的my.cnf吗？
从一些重度使用的表丢失索引。
表types为MyISAM，然后一些长时间运行的SELECT与大量的UPDATE / INSERT / DELETE活动结合导致巨大的查询队列。 这实际上是我认为可能是你的问题 ：绝对肯定你的表是InnoDB格式，这个表是不是意外（甚至是目的）在MyISAM？
在my.cnf中太小的tmp_table_size值; 这可能是您的数据库运行多种查询，大量结果集或类似的情况。 太小的tmp_table_size会导致MySQL创build查询所需的tmp表，而不是将其存储到RAM中。 对于一个查询来说，这并不是一件坏事，但是如果许多查询同时进行，那么您的硬盘性能将会是一个很大的瓶颈。 这是我怀疑现在可能会出现的问题。
数据库位于SAN或其他存储上，出于任何原因，SAN本身都会变慢; 也许其他一些服务器正在大量使用它。
文件系统和/或I / O电梯正在损坏性能。 例如，如果你有一个典型的Linux发行版，他们现在被捆绑CFQ作为默认的I / O电梯。 这可能不是最适合数据库使用的地方 – 截止date或预期好得多，我通常使用截止date 。 如果您有疑问，我可以指导您如何检查和/或更改当前的I / O电梯 – 操作是安全的，可以在线完成。 当涉及到文件系统时，ext3可能不是数据库文件数量最多的高性能文件系统，特别是在并发性较高的情况下。
然后给你一些问题：
如果是InnoDB， SHOW GLOBAL INNODB STATUS在尖峰期间会告诉你什么？
你的网站需要访问的表是巨大的吗？ 我们在谈论数千行，数百万行…？ 而存储方面，他们是否消耗大量的磁盘空间？
你有什么操作系统在使用？ 什么是文件系统？ 文件系统是否可以调整？ 数据库是位于本地磁盘还是某种共享存储（如SAN）？
你有24 GB的内存，是的。 但是在峰值期间free报告给你的是什么？
你运行什么样的网站？ 它是否容易caching（如新闻网站，内容相对较less改变），还是Facebook式的超级dynamic网站？