![如何调试 apache 的超时错误?](https://linux22.com/image/669035/%E5%A6%82%E4%BD%95%E8%B0%83%E8%AF%95%20apache%20%E7%9A%84%E8%B6%85%E6%97%B6%E9%94%99%E8%AF%AF%EF%BC%9F.png)
我不确定这个问题是否属于 ServerFault 还是 StackOverflow,但由于我猜测我需要在服务器端调试这个问题,所以我选择使用 ServerFault。
问题
我们正在为一些客户运行一个共享的网站托管服务器。除了一个客户的网站之外,一切都运行顺利。每周大约有 2 到 3 天,我们的监视器检测到短暂的停机时间,因为 Apache 不会在 30 秒内提供页面,而是在 60 到 120 秒之间。我用自己的桌面检查了一次以确认:网站持续加载了 80 秒,然后突然加载。负载没有增加,请求没有比正常情况更多,服务器上的其他网站加载完美。
我们之前遇到过某个特定插件的问题:该插件与作者的服务器联系以确认许可证密钥。当无法访问此服务器时,Wordpress 无法继续加载,并出现与现在相同的症状。我们注意到这一点是因为有一天他们的服务器停机了几个小时,我们有时间逐一禁用和启用所有插件。根据插件作者的说法,问题现在已经解决。
我强烈地感觉到我们又遇到了同样的问题,也许是同一个插件,也可能不是。但由于停机时间太短(通常不超过 2 分钟),我不知道如何调试此超时错误。
我想到的事情
通常我会逐个禁用插件,但在我连接到数据库禁用插件之前,网站又恢复了。由于停机没有规律,我无法随时待命。Apache 日志没有显示任何错误:我只能看到来自用户的请求,并且看到一段时间内没有提供任何文件。
我的第二个想法是运行 Apache 进程的堆栈跟踪。我确信这会揭示 Apache 在哪里等待了这么长时间。但由于服务器每分钟收到超过 30 个请求,日志文件会在几个小时内变得非常大,这将使我们无法找到正确的请求。
相关服务器规格
CentOS Linux release 7.0.1406 (Core)
Kernel 3.10.0-123.el7.x86_64
Apache/2.4.12 with mod_ruid2
PHP 5.4.38 (cli)
mysql Ver 15.1 Distrib 5.5.41-MariaDB, for Linux (x86_64) using readline 5.1
All compiled by DirectAdmin 1.48.3
有想法吗?
谁能想出一个好方法来调试这个非常具体的问题?任何帮助都非常感谢!
编辑:
- 慢查询日志在慢速请求期间不会报告任何慢速查询。
答案1
如果 Apache 仍可访问,我将首先抓取扩展状态页面以查看目前正在处理哪些请求。如果有一个长时间运行的请求,您甚至可以跟踪它,pid 应该在状态中可见(由于您有 mod_ruid2,我猜您运行 mod_php 和 prefork MPM,因此一个进程一次只能处理一个请求)。
也许重新配置 Customlog,并记录处理请求所需的时间,以便以后您可以识别缓慢的请求。
一旦出现缓慢的请求,看看是否可以重现。如果是,那么调试起来就更容易了,你甚至可以添加 xdebug 来进行 PHP 分析/调试。
还要查看挂起时正在运行哪些 MySQL 查询,也许是 MySQL 慢查询/锁定问题。
正如您所说,也可能是网络 API 问题。
当你别无选择时,也许只能和老板谈谈,然后踢出该用户。根据服务器上有多少其他网站,服务器的健康状况可能比网站本身更重要。
答案2
正如我提到的,我们怀疑其中一个插件是导致当前问题的原因。早些时候,当他们的许可证服务器瘫痪时,我们的网站也瘫痪了。他们说这个问题在他们最近的一次更新中已经修复了,但由于我们瘫痪的时间太长,我对此表示怀疑。
我们最终按照以下方式调试:
- 我们对正常请求进行了 strace,看看页面是如何加载的。
- 如果这个插件有问题,它可能会通过 TCP 端口 80 与许可证服务器联系。我们之前没有想到这一点,但这对我们很有帮助:我们在 IP 表中阻止了这个端口,以模拟许可证服务器超时(确保将 127.0.0.1 列入 IP 表白名单,以免它被永久阻止)。
- 我们再次执行 strace 并加载页面:这次,页面没有加载,卡住了。几秒钟后,我们关闭了 strace,然后查看了文件。
strace 的最后一行是文件的加载:/wp-content/plugins/[plugin-name]/[file-of-plugin].php。Apache 无法传递此插件,直到我们再次解除对 80 端口的封锁。
我们删除了该插件,此后再也没有遇到过停机。这是一个非常罕见的问题,但我希望我的回答对遇到同样问题的人有所帮助。
感谢大家的评论和回答。我们非常感激,这确实帮助我们思考解决方案。