Wordpress 环境和超高使用率 (PHP-FPM)
Wordpress Environment and Exceedingly high usage (PHP-FPM)
我 运行 我服务器上的一个 Wordpress 实例。我的服务器一次至少需要支持1000个并发。
我在 Apache 上使用 PHP-FPM (PHP 5.4) 与 FastCGI 以及 Memcache 和 APC 作为我的选择缓存。我们有两个 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.
根据我目前提供的信息，您能否帮助我找到进入的方向，以便开始诊断此问题？如果需要，我可以提供更多信息。
这些错误在 WordPress 的两种情况下很常见——XMLRPC 攻击或包装器配置不允许生成所需的 FastCGI。前面的 Apache2 与 Nginx 的组合问题太广泛了。我写的是步骤。
FastCGI有效防止站点被拒绝服务攻击或因内存泄漏导致的崩溃。对于 Nginx PHP-FPM，这种情况总是需要检查 XMLRPC 攻击（或类似的暴力破解）并阻止它。如果一个IP在一天之内请求600次，显然是攻击。所以上面是第一步，你在检查XMLRPC攻击，阻止WP臭名昭着的XMLRPC文件加上重复请求的次数很少的IP。 Here is written here to how to check fake PHP5-FPM attack - wordpress-xml-rpc-attack-fake-php5-fpm-error logs for Nginx （你是 Apache2，前面有 Nginx，你可以使用我在该指南中编写的命令来提取错误或IP）。
作为 第二步，Apache2 不完整 header + 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
我们还需要从 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 访问等。
我 运行 我服务器上的一个 Wordpress 实例。我的服务器一次至少需要支持1000个并发。
我在 Apache 上使用 PHP-FPM (PHP 5.4) 与 FastCGI 以及 Memcache 和 APC 作为我的选择缓存。我们有两个 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.
根据我目前提供的信息，您能否帮助我找到进入的方向，以便开始诊断此问题？如果需要，我可以提供更多信息。
这些错误在 WordPress 的两种情况下很常见——XMLRPC 攻击或包装器配置不允许生成所需的 FastCGI。前面的 Apache2 与 Nginx 的组合问题太广泛了。我写的是步骤。
FastCGI有效防止站点被拒绝服务攻击或因内存泄漏导致的崩溃。对于 Nginx PHP-FPM，这种情况总是需要检查 XMLRPC 攻击（或类似的暴力破解）并阻止它。如果一个IP在一天之内请求600次，显然是攻击。所以上面是第一步，你在检查XMLRPC攻击，阻止WP臭名昭着的XMLRPC文件加上重复请求的次数很少的IP。 Here is written here to how to check fake PHP5-FPM attack - wordpress-xml-rpc-attack-fake-php5-fpm-error logs for Nginx （你是 Apache2，前面有 Nginx，你可以使用我在该指南中编写的命令来提取错误或IP）。
作为 第二步，Apache2 不完整 header + 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
我们还需要从 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访问等。