我们遇到了一个问题，我们的 rackspace wordpress 服务器在发送一封电子邮件后，在中等流量下崩溃。
服务器规格如下：
CPU 2 vCPUs
RAM 2 GB
System Disk 80 GB
Network 240 Mb / s
Disk I/O Good
跑步：
Centos 7.0
Wordpress 4.3.1
Httpd 2.4.6
PHP 5.4.11
MariaDB 5.5.41
据我所知，安装过程非常标准，数据库也非常标准、索引齐全且相当小。我们也是 wordpress 对象缓存。
根据 New Relic 的数据，在正常流量期间，网站大约 80% 的时间花在 PHP 上，15% 的时间花在 Web 外部，只有一小部分时间花在数据库中。平均标准页面应用时间约为 800 毫秒，这对我来说确实很慢。
在 1 分钟内运行 250 个连接的负载测试会导致连接时间逐渐变长，然后在大约 30 分钟后开始超时，并且服务器变得无响应（即使流量减少）。它需要硬重启才能再次恢复活动状态。
我无法使用 putty 进行连接，并且主页在超时和返回可怕的“建立数据库连接错误”之间徘徊。
使用 rackspace 监控代理进行最近的测试，似乎 CPU 在死机前达到最大值 100%，使用的内存峰值约为 1.6GB，可用内存降至约 100MB。似乎也使用了约 2GB 的交换内存（总共 4GB）。标准使用率似乎是约 15% 的 CPU、800MB 内存和 400MB 交换。
我们的 Apache 配置没有设置以下任何一项（没有文件/etc）；Timeout、KeepAlive、MaxKeepAliveRequests、KeepAliveTimeout；所以我猜它使用的是默认值。
我查看了 mariadb 设置：
innodb_buffer_pool_size = 1400M
max_user_connections = 0
这似乎不是原因。
我也打开了 performance_schema，但我真的不知道我在寻找什么。我甚至不确定 DB 是不是问题所在。
我很想升级这个实例，但是我更希望能够更清楚地了解瓶颈在哪里以及是什么原因导致服务器崩溃，而不是仅仅让它变慢。
有什么想法可以开始吗？似乎有很多可能的调整和大量信息。
答案1
在任何事件中，密切监控都是至关重要的。正如我们所见，真相大白：
使用 rackspace 监控代理进行最近的测试，似乎 CPU 在死机前达到最大值 100%，使用的内存峰值约为 1.6GB，可用内存降至约 100MB。似乎也使用了约 2GB 的交换内存（总共 4GB）。标准使用率似乎是约 15% 的 CPU、800MB 内存和 400MB 交换。
众所周知，PHP 占用大量 CPU。您已经使用了所有可用的 CPU 和几乎所有可用的 RAM。
您应该首先采取措施来解决这个问题，例如操作码缓存（例如 Zend OPcache）和文件缓存（例如 W3 Total Cache WordPress 插件）。如果这些方法没有帮助足够的，那么就该升级实例了。
答案2
您可能只是同时运行了太多进程，内存不足，并且交换空间被占用。也可能是其他东西被锁定了，但请先处理这个问题，然后再查看您的情况。
您还没有告诉我们您使用的是 mod_php 还是类似 php-fpm 的东西。后者可以更好地处理负载，但无论哪种情况，请确保您运行的 php 进程数不要超过您内存所能容纳的数目。您可能不会从运行超过 5 个或 10 个进程中获得任何性能优势，但默认运行 mod_php 时，运行的进程数将远远超过您内存所能容纳的数目。此外，每 30 个左右的请求回收一次进程。如果您为数据库和操作系统分配 1GB，那么您的其他 GB 可能无法处理 10 个 WordPress 进程。查看它们占用了多少内存，然后计算出来，留出一点空间。在正常情况下，您不应该使用任何交换。
查看您的保持活动设置。使用 Apache 时，您最好将其关闭，或将其设置为 1 秒。Nginx 处理保持活动要好得多。事实上，这是 nginx 可能在 WordPress 等 php 应用程序中表现更好的唯一真正重要的原因（尽管这是以不太令人满意的配置为代价的）。这很可能不是您测试的一个因素，但对于真正的浏览器来说很重要。
CPU 100% 让我很惊讶。使用 top 查看正在使用什么。还要记住，100% 通常意味着一个核心 100% 被使用。您可能只是看到一个 cron 作业启动，对于 WordPress 来说，这通常不是“cron”，而是在处理 Web 请求时作为额外作业运行。缺少操作码缓存也可能导致 CPU 使用率过高。