php - 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-error Nginx 的日志(您是前面带有 Nginx 的 Apache2，您可以使用我在该指南中编写的命令来提取错误或 IP)。

作为第二步，Apache2 + PHP-FPM 本身不完整的 header 需要查看您的 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

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

fastcgi_buffers 256 16k;
fastcgi_max_temp_file_size 0;

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

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

此外，作为第五步，有 xdebug profiler用于检查。

注释:

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