Performance PHP5-FPM随机开始消耗大量CPU

我遇到了一个非常奇怪的问题，我不知道如何进一步调试。我有一个NGINX+PHP5-FPM+APC亚马逊Ubuntu实例，上面安装了一个网站，这是一个复杂的PHP框架。在试图调试这个问题时，我将流程简化为：包括许多大型类，创建主要对象，启动会话，从memcached检索配置数组，从memcached检索XML文件，包括HTML模板，将输出发送到客户端

然后我使用

http\u-load

工具将网站置于每秒20个请求的负载下：

http\u-load-timeout 10-rate 20-fetches 10000./url.txt

接下来发生的事情很奇怪<代码>顶部显示了一组php5 fpm进程，每个进程占用了几%的CPU，所有进程都运行平稳，如下所示：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28440 www-data 20 0 67352 10m 5372 S 4.3 1.8 0:20.33 php5-fpm
28431 www-data 20 0 67608 10m 5304 S 3.3 1.8 0:16.77 php5-fpm
28444 www-data 20 0 67352 10m 5372 S 3.3 1.8 0:17.17 php5-fpm
28445 www-data 20 0 67352 10m 5372 S 3.0 1.8 0:16.83 php5-fpm
28422 www-data 20 0 67608 10m 5292 S 2.3 1.8 0:18.99 php5-fpm
28424 www-data 20 0 67352 10m 5368 S 2.0 1.8 0:16.59 php5-fpm
28438 www-data 20 0 67608 10m 5304 S 2.0 1.8 0:17.91 php5-fpm
28439 www-data 20 0 67608 10m 5304 S 2.0 1.8 0:23.34 php5-fpm
28423 www-data 20 0 67608 10m 5292 S 1.7 1.8 0:20.02 php5-fpm
28430 www-data 20 0 67608 10m 5300 S 1.7 1.8 0:15.77 php5-fpm
28433 www-data 20 0 67352 10m 5372 S 1.7 1.8 0:17.08 php5-fpm
28434 www-data 20 0 67608 10m 5292 S 1.7 1.8 0:18.56 php5-fpm
20648 memcache 20 0 51568 8192 708 S 1.3 1.3 2:51.06 memcached
28420 www-data 20 0 69876 13m 6300 S 1.3 2.3 0:20.89 php5-fpm
28421 www-data 20 0 67608 10m 5300 S 1.3 1.8 0:21.19 php5-fpm
28429 www-data 20 0 9524 2260 992 S 1.3 0.4 0:11.68 nginx
28435 www-data 20 0 67608 10m 5304 S 1.3 1.8 0:18.58 php5-fpm
28437 www-data 20 0 67352 10m 5372 S 1.3 1.8 0:17.87 php5-fpm
28441 www-data 20 0 67608 10m 5292 S 1.3 1.8 0:20.75 php5-fpm

然后经过一段时间（可能在1秒到分钟之间），几个（通常是两个）php5 fpm进程突然消耗了所有CPU：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28436 www-data 20 0 67608 10m 5304 R 48.5 1.8 0:23.68 php5-fpm
28548 www-data 20 0 67608 10m 5276 R 45.2 1.7 0:07.62 php5-fpm
28434 www-data 20 0 67608 10m 5292 R 2.0 1.8 0:23.28 php5-fpm
28439 www-data 20 0 67608 10m 5304 R 2.0 1.8 0:26.63 php5-fpm

此时，所有内容都被卡住，所有新的HTTP请求都超时。如果我停止http_加载工具，php5 fpm将在那里挂起很多分钟。有趣的是，如果我执行

php5 fpm stop

，php5 fpm进程将消失，但任何使用文件系统的命令都会在执行时出现问题。例如，如果我尝试通过ssh下载文件，

top

将显示以下内容，启动实际下载需要很多分钟：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3298 sshd 20 0 7032 876 416 R 75.2 0.1 0:04.52 sshd
3297 sshd 20 0 7032 876 416 R 24.9 0.1 0:04.49 sshd

PHP错误日志通常包含以下内容：

[05-Dec-2012 20:31:39] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 0 idle, and 58 total children
[05-Dec-2012 20:32:08] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 0 idle, and 66 total children

Nginx错误日志中充斥着以下条目：

2012/12/05 20:31:36 [error] 4800#0: *5559 connect() to unix:/dev/shm/php-fpm-www.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: ..., server: ec2-....compute-1.amazonaws.com, request: "GET /usa/index.php?page=contact_us HTTP/1.0", upstream: "fastcgi://unix:/dev/shm/php-fpm-www.sock:", host: "ec2-....compute-1.amazonaws.com"

PHP-FPM慢速日志没有显示任何有趣的内容，交换从未发生过，我也没有收集到关于这个问题的任何其他有趣的事实。我已经经历了多次配置文件更改的迭代，最近的一次是

nginx.conf：

pool.d/www.conf：

==更新1===

网站的配置：

==更新2===

还发现

dmesg

报告了如下错误

[6483131.164331] php5-fpm[28687]: segfault at b6ec8ff4 ip b78c3c32 sp bff551f0 error 4 in ld-2.13.so[b78b5000+1c000]

==更新3===

我们有一个新的AmazonEC2微实例以防万一，以排除可能的硬件问题。另外，我现在使用php fastcgi来排除可能的fpm错误。其他差异都很小，我认为唯一的变化是Ubuntu->Debian。同样的问题仍然存在，只是现在服务器在max_execution_时间秒后设法稍微恢复（然后再次出现峰值）

我尝试使用一个单独的test.php，我不确定这是否是同一个问题，但至少在

top

中看起来是一样的。我创建了一个test.php并包含了一堆属于我们框架的lib。lib除了定义类或包含其他定义类的lib之外，什么都不做。我与APC进行了检查，所有这些都得到了它的成功服务。我开始以每秒200个请求的速度对test.php施加压力，一段时间后，同样的事情发生了。除了现在我设法得到一些错误说“太多打开的文件”。但这种情况并不总是发生，有时它只是开始超时而没有输出错误，一些php进程被卡住，占用了所有CPU。我只玩了一点，但我认为这里有一个相关性-通过控制包含的lib的数量或稍微不同的请求/秒速率，我可以控制CPU峰值何时发生。我增加了相关的OS变量，但问题仍然存在，尽管它需要更长的时间才能发生（还请注意，我已将限制设置为比我在测试期间执行的请求总数大N倍的值）

---

因此，到目前为止，我能给出的下一个最好也是唯一的解释是，即使APC应该从内存中提取文件，但在内部，它的实现方式仍然是在调用PHP include-s时使用文件描述符。或者是因为它会延迟释放它们，或者在某个不幸的时刻，太多的请求同时到达，所以系统会运行我们的描述符，新到达的HTTP请求会很快堆积成一个巨大的队列。我将尝试以某种方式对此进行测试。

我已经运行了一个具有类似配置的网站好几个月了，没有停机时间。我看了一下你的配置，看起来还可以。也就是说，我很久以前做过配置

我会考虑将<代码> PM.Max请求（＝10000）/代码>更合理，如<代码> PM.Max请求（＝500）< /代码>。这只是意味着“不要将每个实例用于超过X个请求”。最好不要将这个数字设置得太高，因为这样做可以让您对可能出现的PHP引擎错误保持弹性

我认为真正的问题很可能出现在PHP脚本中。如果不知道更多，很难说

编辑： 考虑不注释<代码>；request\u terminate\u timeout=0并将其设置为类似于

request\u terminate\u timeout=20

。您的脚本需要在20秒内完成。你很可能会看到行为的改变，但我认为你的网站可能会保持活跃。这将表明一个PHP脚本错误

EDIT2：我自己的php fpm配置如下：

[example.com]
listen = /var/run/sockets/example.com.socket
user = www-data
group = www-data
pm = dynamic
pm.start_servers = 5
pm.max_children = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500
php_flag[expose_php] = off
php_flag[short_open_tag] = on

EDIT3：我在你的nginx配置中发现了一些意想不到的东西，但可能没什么

您正在使用上的

fastcgi\u ignore\u client\u abort在较旧版本的nginx下，这会导致工作进程出现问题。我自己还没有看到这个问题，因为我正在运行一个最新版本的自定义编译。以下是nginx站点上的问题描述：

在1.0.2中，当
fastcgi_ignore_client_abort设置为on，这可能导致工作进程
处理断层。将fastcgi\u忽略\u客户端\u中止切换回
默认设置（关闭）应解决此问题

我也有同样的问题。我试着重新配置PHP-FPM和NGINX，但没有成功。我们的一位同事禁用了v8js.php（），解决了这个问题。我建议禁用任何php模块，直到发现问题为止
[example.com]
listen = /var/run/sockets/example.com.socket
user = www-data
group = www-data
pm = dynamic
pm.start_servers = 5
pm.max_children = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500
php_flag[expose_php] = off
php_flag[short_open_tag] = on

pm = dynamic

pm = ondemand

request_slowlog_timeout = 10
slowlog = /var/log/php-fpm/slow.$pool.log

[28-Dec-2018 14:56:55]  [pool laravel] pid 19061
script_filename = /public_html/index.php
[0x00007efdda4d8100] hasChildren() /public_html/laravel/vendor/symfony/finder/Iterator/ExcludeDirectoryFilterIterator.php:75
[0x00007ffe31cd9e40] hasChildren() unknown:0
[0x00007ffe31cda200] next() unknown:0
[0x00007ffe31cda540] next() unknown:0
[0x00007ffe31cda880] next() unknown:0
[0x00007efdda4d7fa8] gc() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Session/FileSessionHandler.php:91
[0x00007efdda4d7e50] gc() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Session/Middleware.php:159
[0x00007efdda4d7d48] collectGarbage() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Session/Middleware.php:128
[0x00007efdda4d7c20] closeSession() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Session/Middleware.php:79
[0x00007efdda4d7ac8] handle() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Cookie/Queue.php:47
[0x00007efdda4d7930] handle() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Cookie/Guard.php:51
[0x00007efdda4d7818] handle() /public_html/laravel/vendor/stack/builder/src/Stack/StackedHttpKernel.php:23
[0x00007efdda4d76e0] handle() /public_html/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:641
[0x00007efdda4d7598] run() 
/public_html/index.php:51

"cookie" "session" "collectGarbage()" "laravel"