|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2021-02-12 15:21 UTC] micha at dietpi dot com
Description:
------------
I enabled the PHP-FPM status page and configured a handler in Apache2:
```
<Location /status>
SetHandler "proxy:unix:/run/php/php8.0-fpm.sock|fcgi://localhost/status"
</Location>
```
This is the result:
```
pool: www
process manager: static
start time: 28/Jan/2021:15:53:44 +0100
start since: 1147547
accepted conn: 1054191
listen queue: 0
max listen queue: 0
listen queue len: 0
idle processes: 11
active processes: 1
total processes: 12
max active processes: 12
max children reached: 0
slow requests: 0
```
As can be seen, while all running processes have been used concurrently (this is the case after a few hours already, so not a very rare event), the listen queue stays at zero. Especially the `listen queue len` stays at zero, even that `listen.backlog = 1024` is applied in the pool configuration and as well system-wide a sufficient backlog is permitted:
```
net.core.somaxconn = 2048
net.ipv4.tcp_max_syn_backlog = 1024
```
This is on PHP8.0.2, but it was the same before on PHP8.0.1 and PHP7.4.
Steps to reproduce the behavior:
1. Install Debian Bullseye
2. Install Apache2 and PHP-FPM
3. Enable the PHP-FPM status page and the related handler in Apache2
4. Cause more concurrent requests than `pm.max_children`
5. Watch PHP-FPM status page to show `listen queue len` and `max listen queue` being zero.
Probably related bug report: https://bugs.php.net/bug.php?id=76323
Expected result:
----------------
I would expect that `listen queue len` matches `listen.backlog` and that I do see a non-zero value at `max listen queue`, when the process limit is hit regularly. But probably in this setup it is handled differently? At least connections are not dropped from what I can say, no related error messages appear in either PHP or Apache2 logs, so in fact requests are queried somewhere.
Actual result:
--------------
listen queue: 0
max listen queue: 0
listen queue len: 0
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 01 13:00:01 2025 UTC |
Many thanks for providing the scripts. Indeed I can also verify with PHP8.0 that this method works fine and "Recv-Q" indeed shows the current query length. I did monitoring with this one-liner from shell: ``` while sleep 1; do value=$(ss -lxn | mawk '/php/{print $3}'); (( $value )) && echo "$value"; done ``` However, this is of course everything else than precise as it only takes a snapshot of the current query length at defined interval, which, considering the speed in which PHP requests are handled, will unlikely ever show the real maximum reached. For the current query length ("listen queue:" on status page) this however works fine. Of course PHP-FPM shouldn't execute any external command but try to obtain the information with the methods "ss" uses ;). I wonder whether /proc/<PID>/net/netstat contains what we are looking for. But so far I couldn't identify any of the long value list a maximum reached query length. Probably there are other stats provided by the kernel in /sys or /proc somewhere? Best regards, Micha