我花了几天的时间试图解决同样的问题,我什至使用了 deregister_heartbeat 代码 - 没有效果。我想分享一个解决方案,以防止 Apache / MySQL 在您尝试找出发生的情况时死亡。
最后,在另一台服务器上创建站点的测试副本并切换到默认主题后,我能够确定子主题中的扩展引擎正在进行 Ajax 调用,这些调用以某种方式超过了取消注册的心跳 - 我们'现在已经放弃了引擎,可能会从头开始编写子主题。
为了给我一些时间,同时跟踪有问题的东西,我需要一种方法在它们占用所有可用空间之前从网络服务器中删除线程——而且我们有一个很大的网络服务器——尽管如此,它仍然导致站点在 Apache 运行仅一个小时后崩溃重新开始。您当然可以使用硬 Apache 重启(在 Debian 机器上apachectl restart或service apache restart)——但这会杀死所有连接——并且在多主机环境中它会搞砸某人。如果您在 *NIX 系统上,您可以执行以下操作,它需要w3m(或可以从 CLI 运行转储的等效盲文模式浏览器,如 elinks、lynx 或 links)
#!/bin/bash
kill `w3m -dump http://<server address>/server-status | grep "admin-ajax.php"|awk '{print $2}'`
确保在杀死后和脚本结束时立即获得反引号。我们基本上使用 w3m 来访问服务器状态页面(您需要在您的 Apache 配置中启用此功能 - 使其仅可从本地 IP 地址使用,它提供了很多东西) - 我们通过 grep 管道传输结果只是磨练处理admin-ajax.php 的进程——然后我们将这些行输入到awk中,awk 基本上将相关PID编号的列表返回给kill命令。
结果是 Apache 中的进程线程将会死掉 - 但会在任何服务器状态列表中显示为没有当前进程的开放插槽的一小段时间- 对您站点的后续命中将再次以正常方式占用这些线程
我们把整个事情放到每 5 分钟左右运行一次的cron任务中——效果是我们让线程出现了,但它们从来没有停留足够长的时间来引起问题。