Wordpress 环境和极高的使用率 (PHP-FPM)

Question

我在我的服务器上运行了一个 Wordpress 实例。我的服务器需要同时支持至少 1,000 个并发。

我在 Apache 上使用 PHP-FPM (PHP 5.4) 和 FastCGI 以及 Memcache 和 APC 用于我的 opt-caching。我们有两个 MySQL 服务器作为从服务器运行。

服务器具有以下资源容量：

Ram: 32GB
CPU: 8 Cores

我运行 Apache 服务器的用户使用以下 ulimit：

Hard: 4096
Soft: 1024

我们间歇性地有停机时间，当停机时间发生在我们身上时，我们会收到来自 Nginx 的 500 个错误（它充当我们在单独服务器上的负载平衡器）。当我们收到这 500 个错误（它们的范围从 500 到 504）时，在 htop 上我可以看到我们已经最大化了我们的 RAM 使用率，并且间歇性地提高了我们的 CPU 使用率（我认为这与数据库有关？）。消耗这些资源的进程是 PHP-FPM 子进程。

我不是系统管理员，我只是开发人员。所以它开始超出我的范围。

php错误日志似乎报告了以下内容：

[Mon Oct 10 12:54:33 2016] [error] [client 155.234.240.16] (104)Connection reset by peer: FastCGI: comm with server "/[MYURL].fcgi" aborted: read failed, referer: [MYURL]
[Mon Oct 10 12:54:33 2016] [error] [client 155.234.240.16] FastCGI: incomplete headers (0 bytes) received from server "/[MYURL].fcgi", referer: [MYURL]
[Mon Oct 10 12:54:34 2016] [error] [client 146.231.88.181] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

根据我迄今为止提供的信息，您能否帮助我找到前进的方向，以便开始诊断此问题？如果需要，我可以提供更多信息。

Answer 1

这些错误在 WordPress 的两种情况下很常见——XMLRPC 攻击或包装器配置不允许需要的 FastCGI 生成。前面结合Apache2和Nginx的问题太大了。我正在写步骤。

FastCGI 有效防止站点被拒绝服务攻击或因内存泄漏而崩溃。对于 Nginx PHP-FPM，这种情况总是需要检查XMLRPC 攻击（或类似的蛮力）并阻止它。如果一个IP一天请求600次，显然是一次攻击。所以以上是第一步，您正在检查 XMLRPC 攻击，阻止臭名昭著的 WP 的 XMLRPC 文件，并获得多次重复请求的 IP。这里写到如何检查假的 PHP5-FPM 攻击 - wordpress-xml-rpc-attack-fake-php5-fpm- Nginx的错误日志（你是 Apache2，前面是 Nginx，你可以使用我写的命令提取错误或 IP 的指南）。

作为第二步，不完整的标题用的Apache2 + PHP-FPM本身需要看您的FCGI包装（/dev/shm/blackmou-php.fcgi）或.htaccess用于FastCGI的产卵。这是包装器配置的示例：

PHP_FCGI_CHILDREN=0 
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=10000
export PHP_FCGI_MAX_REQUESTS

我们还需要memory_limit从php.ini. 对于Nginx上的类似情况，我们调整fastcgi_max_temp_file_size，fastcgi_buffers-

fastcgi_buffers 256 16k;
fastcgi_max_temp_file_size 0;

如果以上不是问题，作为第三步，WP_DEBUG在您的wp-config.php文件中启用。您可能会看到关于插件问题的更好的错误消息，但没有保证。

如果不是问题，作为第四步，停用所有插件并使用默认主题几分钟。如果什么都没有出现，主题或插件有问题。

此外，作为第五步，有用于检查的xdebug 分析器。

注意事项：

• 如果您担心数据库出现故障，请使用WordPress 功能修复数据库。然而这是不太可能的。
• 您应该正确配置了 iptables、fail2ban、限制wp-login.php访问等。