一切都运行良好，然后在 MySQL 从 5.0 升级到 5.1，然后是 5.5 后，出现了一些问题(一些表前缀被搞乱了，丢失了一点数据，但没什么大问题)，我们遇到了这个新问题突然出现。
据我所知，Apache (httpd.conf)、MySQL (my.cnf) 或 PHP (php.ini) 的配置设置没有更改。
我在升级之前检查了 Apache 日志，我们根本没有达到 MaxClients。
现在我们一直点击它(一天 9 次!)，当我们这样做时，服务器上的所有网页都变得完全无法访问，需要重新启动 Apache - 而且在我完成重新启动之前，它们似乎永远无法再次访问，尽管我真的不想等待并看看它是否会出现。
之前我们的 MaxClients 和 ServerLimit 设置为 1000 - 我将其提高到 3000，尽管达到 MaxClients 的频率似乎有所下降，但这种情况仍在发生。我们有 96.0 GB 的 RAM，使用量永远不会超过 30 GB，通常要低得多。
我检查了之前和之后的日志，机器人抓取事件似乎大致相同。
我想知道是否更改了其他一些设置会导致出现这种情况？或者如果有人有任何其他想法，我将非常感激。
最佳答案
我们有一个“PBS”案例:http://techmythsworld.blogspot.com/2011/11/solving-httpd-maxclients-and-modstatus.html
W 不断累积，直到我们不断达到 MaxClients。这个问题可能在某种程度上一直存在，但后来由于升级期间和/或升级前后配置设置的某种变化而加剧，我不确定。但是，我确信我们通过稍微更改代码来修复它，以便进程会在设定的时间段后终止，而不是等待一定数量的循环发生。话虽这么说，使用某种脚本来杀死那些从裂缝中溜走的陈旧进程，然后记录它们可能是个好主意。
如果上述链接出现故障，您将需要使用以下命令通过命令行检查进程:
service httpd fullstatus > outputfile.txt
如果您看到 W 的累积，请向下滚动，如果您发现一两个脚本占其中大部分的模式，那么(那些)很可能就是您的罪魁祸首。为了确保累积是合法的，您可能需要检查一次，然后在一小时后回来查看是否继续。您会注意到 W 的 SS 不断增加(自最近请求开始以来的秒数)。
关于mysql - MySQL 升级后，服务器连续达到 MaxClients，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17055561/