php-fpm进程监视/分析 [英] php-fpm processes monitoring / profiling

问题描述

我最近遇到了一个问题，即php-fpm进程的使用率(与活动进程的数量一样)达到最大可用进程的峰值，并停止了其他脚本的执行，直到有问题的进程完成为止.

I have recently encountered an issue with php-fpm processes usage (As in the amount of active processes) peaking to the maximum available processes and by that stopping execution of other scripts until the problematic processes finish.

更详细地说， 我当前的php-fpm设置是:

In a bit more detail, my current php-fpm settings are:

pm = static
pm.max_children = 100

我正在观看php-fpm的状态页面，大多数情况下该页面显示:

I am watching the php-fpm's status page, which most of the time shows:

total processes: 100
idle processes: 95-99
active processes: 1-5

这是正常的. 但是，每隔几分钟，活动进程数就会在几秒钟内跳到100，然后又恢复到正常的1-5.在那段时间里，服务器上运行的所有其他脚本都只是停留了一段时间. (从浏览器中，您只是看到页面在等待中.)

which is normal. However, ever few minutes the active processes count jumps to 100 for a few seconds, and then goes back to normal of 1-5. in that time all other scripts running on the server are simply stuck for that period of time. (From the browser you simply see the page waiting).

现在，我已经检查了它在特定流量中是否达到峰值，但没有.一天中的流量最少的情况下也会发生这种情况.

Now, i have checked to see if its in specific traffic spikes, but its not. it can also occur with the lowest traffic count of the day.

我相信某个脚本(甚至可能仅在特定情况下)会导致php出于某种原因简单地使用所有可用进程.

I believe that a certain script, maybe even only in specific situations, is causing php to simply use all available processes for some reason.

一旦我们从5.2.X移到PHP 5.4.X，这个问题就开始了

This issue started once we moved to PHP 5.4.X from 5.2.X

我们目前大约有60个网站，因此很难浏览每个网站的页面并进行检查.

We currently have around 60 websites, so its kinda hard going through each website's pages and checking it.

nginx日志中没有任何内容(无论如何都不重要，有一些注意事项等).

There is nothing in the nginx logs (Nothing critical anyway, there are a few Notices and such).

我想做的是以某种方式跟踪/配置文件/监视哪个php-fpm脚本正在使用这些进程，这样我就知道从哪里开始寻找问题了.

What i'm trying to do, is somehow trace/profile/monitor which php-fpm script is using the processes so i will know where to start looking for the problem.

这可能吗?也许是另一种方法?

Is this possible? Maybe a different approach?

更新

以下是1小时内，每1分钟间隔内PHP-FPM进程计数的图表:

Here is a graph of the PHP-FPM process count in 1 hour, in 1 min intervals:

我用红色标记了我正在谈论的跳跃. 峰值时的内存使用量保持不变

I have marked in red the jumps that i'm talking about. The memory usage at the time of the spike stays the same

推荐答案

在您的php-fpm日志文件中，您应该可以看到类似的内容:

In your php-fpm log file you should be able to see something like:

 WARNING: [pool www-images] server reached pm.max_children setting (5), consider raising it.

当活动进程的数量达到极限时.您应该能够将其与传入的请求相关联.

for when the number of active processes hits the limits. You should be able to correlate that with the requests that are coming in.

如果没有显示引起请求的任何模式，则应将缓慢的日志记录添加到php-fpm配置中:

If that doesn't show any pattern of which requests are causing the issue then you should add slow logging to your php-fpm config:

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

这将为每个请求记录的堆栈跟踪记录占用的时间超过slowlog_timeout限制.

The will log a stack trace for each request that takes up more than the slowlog_timeout limit.

如果仍然不显示任何内容，则您的内部应用程序日志中的任何一个都应显示速度下降发生的位置.

If that still doesn't show anything then either your internal application logging should show where the slow down occurs.

如果没有足够的详细信息，则可以最后使用 strace 度假村，它将显示正在进行哪些系统调用.那将产生大量的信息.我建议仅将其附加到单个进程strace -p PID，其中PID是php-fpm实例的processID.

If that doesn't have enough detail then you could use strace as a last resort, which will show which system calls are being made. That will produce a torrent of information. I'd recommend only attaching it to a single process strace -p PID where PID is the processID of a php-fpm instance.

它也可以在当天的流量最少的情况下发生.

it can also occur with the lowest traffic count of the day.

这绝对应该显示在php-fpm慢日志中.但是，如果这仅显示出什么请求很慢，但没有帮助您找出原因，则可以在PHP-FPM配置文件中使用自动前挂起和后挂起文件添加调试.

That should definitely show up in the php-fpm slow logging. However if that only shows you what request are slow, but doesn't help you figure out why, you can add debugging using the auto pre and post-pend files, in your PHP-FPM config file.

php_value[auto_prepend_file]=/php_shared/prepend.php
php_value[auto_append_file]=/php_shared/postpend.php

或者真的很简单

您可以设置PHP-FPM状态页面.

Or really simply

You can set up the PHP-FPM status page.

将此添加到您的PHP-FPM池配置中:

Add this to your PHP-FPM pool config:

pm.status_path = /www-status

并将请求通过nginx传递到PHP-FPM

And pass the requests through nginx to PHP-FPM

location ~ ^/(www-status)$ {
    include       %mysite.root.directory%/conf/fastcgi.conf;
    fastcgi_pass   unix:%phpfpm.socket%/php-fpm-www.sock;

    # or IP address
    # fastcgi_pass 127.0.0.1:9000;

    #If you're fastcgi.conf doesn't set the query_string
    #pass the query string here instead.
    # fastcgi_param  QUERY_STRING  $query_string;


    fastcgi_index index.php;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;

    allow 127.0.0.1;
    allow stats_collector.localdomain;
    allow watchdog.localdomain;
    deny all;
}

然后转到yoursite.com/www-status?full将为您提供所有php-fpm流程的重要内容，例如:

Then going to yoursite.com/www-status?full will give you a big print out of every php-fpm process like:

pool:                 www
process manager:      dynamic
start time:           18/Mar/2013:20:17:21 +1100
start since:          243
accepted conn:        3
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       3
active processes:     1
total processes:      4
max active processes: 1
max children reached: 0
slow requests:        0

************************
pid:                  6233
state:                Idle
start time:           18/Mar/2013:20:17:21 +1100
start since:          243
requests:             1
request duration:     631
request method:       GET
request URI:          /www-status
content length:       0
user:                 -
script:               /documents/projects/intahwebz/intahwebz/basereality/www-status
last request cpu:     0.00
last request memory:  262144

顺便说一句，我敢打赌它是一个愚蠢的查询，它锁定了您的数据库.

btw I bet it some silly query that's locking up your database.

这篇关于php-fpm进程监视/分析的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！