3

这不是典型的问题，但我没有想法，不知道还能去哪里。如果有更好的地方可以问这个问题，请在评论中指出我。谢谢。

情况

我们有这个使用Zend 框架的 Web 应用程序，因此在Apache Web 服务器上以PHP运行。我们使用MySQL进行数据存储，使用memcached进行对象缓存。

该应用程序具有非常独特的用法和加载模式。它是一个移动 Web 应用程序，每一个完整小时，一个 cronjob 都会在数据库中查找有一些信息等待或操作要做的用户，并将这些信息发送到（外部）通知服务器，然后将这些通知推送给他们。用户收到这些通知后，会转到应用程序并使用它，主要是在很短的时间内。一个小时后，同样的事情发生了。

问题

在过去的几周里，该应用程序的使用量真正开始增长。在过去的几天里，我们在发送这些通知期间和之后遇到了非常高的负载和两倍的应用程序响应时间（基本上是每小时一次）。服务器不会崩溃或停止响应请求，它只是变得越来越慢，并且通常需要 20 分钟才能恢复 - 直到整整一个小时再次开始相同的事情。

我们进行了广泛的监控（New Relic，collectd），但我不知道出了什么问题；我找不到瓶颈。这就是你进来的地方：

您能帮我找出问题所在以及如何解决吗？

附加信息

该服务器是 16 核 Intel Xeon（我认为是 8 核超线程）和 12GB RAM，运行 Ubuntu 10.04（Linux 3.2.4-20120307 x86_64）。Apache 是 2.2.x，PHP 是版本 5.3.2-1ubuntu4.11。

如果任何配置信息有助于分析问题，只需评论，我会添加它。

图表

信息

收集

新遗物

（抱歉，这些图表是 gif 图像，而不是同一时间段，但我认为最重要的信息在其中）

4

1 回答 1

2

这个问题几乎可以肯定是基于 MySQL 的。如果您查看最终图表 mysql/mysql_threads，您可以看到线程数在 20:00 达到 200（我假设这是您对 max_connections 的设置）。一旦 max_connections 被击中，事情往往需要一段时间才能恢复。

在一小时前使用mtop监控 MySQL 确实可以帮助您弄清楚发生了什么，但如果您无法安装它，您可以使用SHOW PROCESSLIST;. 在问题发生之前，您需要建立与 mysql 的连接。您可能会看到许多进程排队，当前只有 1 个进程正在执行。这将是最有可能的罪魁祸首。

确定导致问题的查询后，您可以攻击您的代码。如果不了解您的应用程序实际上是如何工作的，我最好的猜测是围绕问题查询使用显式事务可能会解决问题。

祝你好运！

于 2012-04-15T00:41:23.317 回答