如何找出导致应用程序变慢的原因?

3
这不是典型的问题,但我已经没有思路了,也不知道去哪里寻求帮助。如果有更好的地方可以提问,请在评论中指出。谢谢。

情况

我们有一个使用Zend Framework的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。

如果任何配置信息可以帮助分析问题,请在评论中提出,我会添加它们。

图表

信息

collectd

New Relic

(抱歉,这些图是 gif 格式的,并且时间段不同,但我认为最重要的信息都在里面了)


1
我认为首先你应该在服务器变慢时检查mysql连接的响应情况。这可能是延迟的原因。 - Shehzad
能再解释一下吗?我不太明白你的意思,也不知道我需要做什么才能得到这个。 - janpio
SeaLion在这种情况下会更有帮助。对于调试问题的原因,原始输出总是比图形更好。 - Kevin
1个回答

2
问题几乎肯定是基于MySQL的。如果您查看最终图表mysql/mysql_threads,您会看到线程数在20:00达到了200(我假设这是max_connections的设置)。一旦达到max_connections,事情确实需要一些时间才能恢复。
使用 mtop 在整点前监视MySQL将真正帮助您找出问题所在,但如果您无法安装它,您可以只使用 SHOW PROCESSLIST;。您将需要在问题出现之前建立与MySQL的连接。您可能会看到很多排队的进程,只有一个进程在执行。这可能是最有可能的罪魁祸首。
确定导致问题的查询后,您可以着手解决代码问题。没有理解您的应用程序实际工作方式,我最好的猜测是在问题查询周围使用显式事务可能会解决问题。
祝你好运!

谢谢你的回答!max_connections实际上是550,所以它不是罪魁祸首。但这让我回到了“进程”图表。每次出现问题时,进程数都会达到500。如果在整点时少于500,则负载不会那么高。因此,似乎我们达到了打开进程的限制。现在我只需要学习如何确认这一点... - janpio
是的,我仍然会尝试使用mtop。问题是我在这个服务器上只有有限的权限,所以SHOW PROCESSLIST;也没有什么用,因此必须走系统管理员的路线。但看起来很不错。 - janpio
1
通知服务器是否也访问数据库以及 cron 进程?如果您发布每小时 cron 运行的代码,可能会有所帮助。 - user1191247
我没有代码在身边,但是:每小时的定时任务从用户数据库中获取一些数据,将其推送到我们用于通知的外部服务的服务器上,然后更新用户,告诉他们他们收到了通知。它的运行时间也比问题发生的时间短得多(大约90秒,大部分时间用于http请求)。 - janpio

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接