首先我想说的是，在提出自己的问题之前，我已经阅读了至少 10 个相关的 Serverfault 问题...
我目前正在运行一个 Ubuntu 14.04.3 服务器，它有 2GB 的 RAM 和大约 5 个活跃的 WordPress 安装，所有这些都在 Vesta CP 控制面板下进行管理。
通常情况下，它会占用 2GB 内存中的 700MB 左右。但每隔一周左右，所有内存就会神奇地被消耗殆尽，服务器速度就会减慢到几乎停止运行。
如果我通过 SSH 进入它并重新启动 apache，以及清除内存（echo 3 > /proc/sys/vm/drop_caches），它就能再次正常运行。
下面是我的prefork模块的设置，我觉得非常合理：
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 1
MaxSpareServers 5
ServerLimit 10
MaxClients 10
MaxRequestsPerChild 1000
</IfModule>
我甚至启用了 mod_status 并尝试查看哪些 PHP 文件耗时过长，但没有发现任何可疑之处。当然，当我在服务器关闭时查看日志时，它充斥着至少 200 个 PHP 文件，因为它们由于大量内存消耗而无法运行。
我甚至启用了 8GB 的 SWAP 文件，但这似乎只是延迟了不可避免的事情。
以下是该free -m命令每次提取的内容：
root@apache2-ps7881:/home/dhc-user# free -m
total used free shared buffers cached
Mem: 2001 1943 57 35 1 59
-/+ buffers/cache: 1883 118
Swap: 8191 4083 4108
重新启动apache后：
root@apache2-ps7881:/etc/apache2# free -m
total used free shared buffers cached
Mem: 2001 744 1257 65 36 204
-/+ buffers/cache: 503 1498
Swap: 8191 140 8051
以下是/var/log/apache2/error.log：
[Fri Feb 12 08:22:33.063204 2016] [mpm_prefork:error] [pid 2081] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
[Fri Feb 12 13:12:59.819680 2016] [core:warn] [pid 2081] AH00045: child process 6334 still did not exit, sending a SIGTERM
那个“子进程仍然没有退出”的错误持续了数百行。
server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting每次它发生故障时我都会收到该消息。
另一项则error.log揭示了以下内容：
[Fri Feb 12 08:19:55.781598 2016] [:error] [pid 20686] [client 10.10.10.9:54559] PHP Warning: mysqli_connect(): (08004/1040): Too many connections in /[censored]/$
[Fri Feb 12 08:19:55.896491 2016] [:error] [pid 20686] [client 10.10.10.9:54559] Too many connections, referer: http://[censored]
会不会是有一个连接没有关闭？但是会不会造成内存泄漏？
以下是崩溃期间图表所显示内容的一个例子：
答案1
我遇到过类似的问题，Wordpress 网站开始使用大量资源，导致服务器基本无响应。调查日志时，我看到在xmlrpc.php内存占用膨胀的同时，有数百次访问尝试。xmlrpc.php可以使用该方法滥用中的函数作为暴力攻击的力量倍增器system.multicall。
这篇文章更清楚地描述了它的工作原理： https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html
更重要的是，以下是该文章中的一些缓解策略：
保护自己
我曾经建议人们阻止对 xmlrpc.php 的所有访问，但它破坏了某些插件的功能（主要是 JetPack）。考虑到这一点，如果您不使用 JetPack 或任何其他需要 XML-RPC 的插件，那么完全阻止对它的直接访问可能是一个好主意。
如果您无法阻止 XML-RPC，并且您正在使用 WAF（Web 应用程序防火墙），我强烈建议阻止 system.multicall 请求。它在实际中很少使用，可以保护您免受这些放大方法的侵害。
我不使用任何需要访问 xmlrpc.php 的插件，因此我修改了 .htaccess 以拒绝访问。从那时起，再也没有恶意行为者成功破坏该网站。如果您想尝试一下，以下是代码：
使用您选择的文本编辑器，修改 /var/www/html/.htaccess以包含：
<Files "xmlrpc.php">
Order Allow,Deny
deny from all
</Files>
Wordpress 有其他关于强化网站访问的指导原则，请参见此处： https://wordpress.org/support/article/hardening-wordpress/
Wordpress 的登录安全解决方案插件也可能有帮助。我会发布链接，但我缺乏声誉。抱歉！
答案2
看起来网站只是变得很忙，但您说事实并非如此。它正在耗尽服务器资源，因此您可能需要在资源耗尽之前限制资源。
我还会查看 Wordpress 使用的插件和小部件。删除所有不是 100% 必要的内容，进行测试。我见过插件和小部件对 Wordpress 网站造成可怕的影响。至少你应该使用缓存插件，我记得 W3 Total Cache 是最好的。
如果是我的服务器，我会更改服务器的底层架构以使用 Nginx 和 HHVM，包括页面缓存。我有四个 Wordpress 安装和一个在 aws t2.micro 上运行的中等繁忙网站，它占用一个 Xeon 核心的 10%（可突发到一个完整核心）和 1GB 内存，尽管我也使用 Amazon RDS（关系数据库服务）。我的网站加载速度非常快。请注意，此更改不是必需的，您可能可以修复您的配置，它应该可以正常工作，但我不知道如何操作。
我已经写了一个关于在 AWS 上使用 Nginx、HHVM 等设置 Wordpress 的重要教程。你可以点击这里阅读。您可以非常轻松地将其与当前基础架构一起设置，在不同的端口上运行 Nginx，甚至使用相同的 webroot 和数据库 - 但我在测试时会创建一个只读数据库用户。一旦您对其工作感到满意，只需交换端口，您就可以运行 nginx、hhvm，它应该更可靠。如果没有，至少您可能会获得一些社区支持，因为我建议的配置相当标准。
如果您的网站有许多匿名访问者，您可以从 nginx 页面缓存中处理大量请求，这几乎不占用 CPU，也不会影响 PHP。我的小实例每秒可以处理 1000 个缓存页面，有时甚至更多，不确定瓶颈是什么，但它在缓存中仅占用 2% 的 CPU。如果影响 PHP，它每秒只能处理 11 个页面，这是一个巨大的差异，表明执行代码的速度有多慢。它将使您的网站更快。它应该使所有访问者的速度更快，HHVM 比 PHP5 快很多。
答案3
您向我们展示的配置与您的描述“至少 200 个 PHP 文件”以及 top 的输出（显然包含超过 10 个实例）明显相矛盾。清除 vfs 缓存似乎可以消除这些症状，这有点令人担忧——唯一应该产生的影响是降低服务器速度。
所有这些进程都被阻止了 - 它们无法为数据库工作。这里似乎也存在一些严重的文件争用问题。
它看起来像允许过多的连接与阻塞文件锁相结合。后者可能可能是 DOS 攻击，特别是如果您使用默认会话处理程序。如果是这种情况，您的访问日志应该会很明显。
这里没有快速修复方法，但下一步应该是修复配置，使其真正发挥作用，并禁用全部WordPress 插件。这些插件的质量差别很大。
事实上，我们应该投票关闭这个范围太广的项目。