Bug #80739 [NEW]: PHP-FPM status page shows listen queue 0
| From: | micha at dietpi dot com | Date: | Fri, 12 Feb 2021 15:21:52 +0000 |
| Subject: | Bug #80739 [NEW]: PHP-FPM status page shows listen queue 0 | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-232093@lists.php.net to get a copy of this message | ||
From: micha at dietpi dot com
Operating system: Debian Bullseye
PHP version: 8.0.2
Package: FPM related
Bug Type: Bug
Bug description:PHP-FPM status page shows listen queue 0
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
--
Edit bug report at https://bugs.php.net/bug.php?id=80739&edit=1
--
Fix committed: https://bugs.php.net/fix.php?id=80739&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=80739&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=80739&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=80739&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=80739&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=80739&r=support
Expected behavior: https://bugs.php.net/fix.php?id=80739&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=80739&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=80739&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=80739&r=globals
PHP version support discontinued: https://bugs.php.net/fix.php?id=80739&r=phptooold
Daylight Savings: https://bugs.php.net/fix.php?id=80739&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=80739&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=80739&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=80739&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=80739&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=80739&r=mysqlcfg