我遇到了一个非常奇怪的问题,我不确定如何进一步调试。我有一个NGINX + PHP5-FPM + APC Amazon Ubuntu实例,并且安装了一个网站,这是一个复杂的PHP框架。在尝试调试问题时,我减少了流程:包含了很多大类,创建了主对象,启动了会话,从memcached中检索了配置数组,从memcached中检索了XML文件,HTML包含模板,输出发送到客户端。
然后我使用http_load
工具将网站置于每秒20个请求的负载下:http_load -timeout 10 -rate 20 -fetches 10000 ./urls.txt
接下来发生的事情很奇怪。 top
显示了一堆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
然后在一秒钟到几分钟之间的任何时间,几个(通常是两个)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_load工具,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:http://pastebin.com/uaD56hJF
pool.d / www.conf:http://pastebin.com/mFeeUULC
===更新1 ===
网站的配置:http://pastebin.com/qvinVNhB
===更新2 ===
还发现dmesg
报告此类错误
[6483131.164331] php5-fpm[28687]: segfault at b6ec8ff4 ip b78c3c32 sp bff551f0 error 4 in ld-2.13.so[b78b5000+1c000]
===更新3 ===
我们有一个新的Amazon EC2微型实例以防万一,以排除可能的硬件问题。此外我现在使用php-fastcgi来排除可能的fpm错误。其他差异很小,我认为唯一改变的是Ubuntu-> Debian。同样的问题仍然发生,除了现在服务器在max_execution_time秒之后设置稍微恢复(然后再次尖峰)。
我尝试使用单独的test.php,我不确定它是否是同一个问题,但至少在top
它看起来是一样的。我创建了一个test.php并包含了一堆属于我们框架的库。除了定义类或包含定义类的其他库之外,libs不做任何事情。我检查了APC,所有这些都成功地得到了它。我开始向test.php施加压力,每秒200次请求,过了一段时间后,同样的事情发生了。除了现在我设法得到一些错误说“太多打开文件”。它总是不会发生,有时它只是在没有输出错误的情况下开始超时,并且一些php进程卡在消耗所有CPU。我只玩了一点但是我觉得这里有一个相关性 - 通过控制包含的库的数量或略微变化的请求/秒速率,我可以控制CPU峰值何时发生。我增加了相关的操作系统变量,但问题仍然存在,尽管它需要更长时间才能发生(同时请注意,我已将限值设置为N次大于我在测试期间执行的请求总数)。
fs.file-max = 70000
...
* soft nofile 10000
* hard nofile 30000
...
worker_rlimit_nofile 10000;
...
(reloaded all the configs and made sure the new system vars actually took affect)
所以到目前为止我能想到的下一个最好也是唯一的解释是,尽管APC应该从内存中提取文件,但在内部实现时,只要调用PHP include-s,它仍以使用文件描述符的方式实现。并且要么因为它延迟释放它们,要么在某个不幸的时刻有太多请求在同一时刻到达,系统会运行我们的描述符,并且新到达的HTTP请求会快速堆叠到一个巨大的队列中。我会尝试以某种方式测试它。
答案 0 :(得分:9)
我运行了一个具有类似配置的网站已有好几个月,没有停机时间。我已经看过你的配置了,看起来还不错。话虽这么说,我不久前做了我的配置。
我会考虑将pm.max_requests = 10000
缩减为更合理的内容,例如pm.max_requests = 500
。这只是意味着“不要将每个实例用于超过X个请求数”。最好不要将这个数字设置得太高,因为这样做可以让你在可能的PHP引擎错误方面具有弹性。
我认为真正的问题很可能出现在PHP脚本中。如果不了解更多,很难说。
编辑:
请考虑取消注释;request_terminate_timeout = 0
并将其设置为request_terminate_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_ignore_client_abort on;
,这会在旧版本的nginx下导致工作进程出现问题。我自己没有看到这个问题,因为我正在运行最近版本的自定义编译。以下是nginx网站上问题的描述:
在1.0.2中,POST请求未正确处理 fastcgi_ignore_client_abort设置为可以导致工作人员 过程分割。将fastcgi_ignore_client_abort切换回 默认(关闭)应解决此问题。
答案 1 :(得分:3)
简单的技巧但非常有用,可以将处理器使用率降低50%,只需编辑你的php-fpm配置:
pm = dynamic
并将其更改为:
pm = ondemand
答案 2 :(得分:1)
我现在正在经历同样的问题,并希望指出这篇文章:
它必须是您的PHP脚本之一。看看你是否可以连接失控进程ID和阻止你的.php脚本文件之间的点。
有趣的是,这已经在一台无可挑剔的服务器上了。我认为WordPress升级(插件或核心)可能是非常负责任的。
答案 3 :(得分:0)
我遇到了同样的问题。我尝试重新配置PHP-FPM和NGINX,并没有走得太远。我们其中一个人禁用了v8js.php(http://php.net/manual/en/book.v8js.php)并解决了这个问题。我建议在找到麻烦制造者之前禁用任何php模块。希望这有助于某人。
答案 4 :(得分:0)
我服务器上的PHP-FPM行为与您相同。瓶颈肯定在某处。
问题变成了:如何在Nginx-PHP-FPM-Mysql上找到瓶颈?
找出最快的方法是:为PHP-FPM启用Slowlog。
将以下几行添加到您的php-fpm.conf池中,并确保该路径存在
request_slowlog_timeout = 10
slowlog = /var/log/php-fpm/slow.$pool.log
通过阅读日志回溯,您可以了解为什么PHP-FPM花了这么多CPU或超时。这是我的情况:
[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"
我一直在搜索和TADA,Laravel使用RANDOM方法来清除过期的会话。在我的配置中,PHP使用SSD来处理Session。
当会话数变得“非常大”时,这将使PHP花更多的时间来处理=>高CPU使用率。
我们可能有很多瓶颈, 当我们对其进行“调试”时,我们才知道。
进行很好的调查。