我不确定这个问题是否属于 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 端口的封锁。
我们删除了该插件，此后再也没有遇到过停机。这是一个非常罕见的问题，但我希望我的回答对遇到同样问题的人有所帮助。
感谢大家的评论和回答。我们非常感激，这确实帮助我们思考解决方案。