Bug #69724 [Asn->Opn]: pm.ondemand forks fewer child workers than it should
| From: | kalle@php.net | Date: | Tue, 24 Oct 2017 07:45:34 +0000 |
| Subject: | Bug #69724 [Asn->Opn]: pm.ondemand forks fewer child workers than it should | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-212157@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=69724&edit=1
ID: 69724
Updated by: kalle@php.net
Reported by: barry at jaspan dot org
Summary: pm.ondemand forks fewer child workers than it should
-Status: Assigned
+Status: Open
Type: Bug
Package: FPM related
Operating System: Linux
PHP Version: 5.5.25
-Assigned To: fat
+Assigned To:
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2015-05-28 23:10:16] barry at jaspan dot org
Description:
------------
The FPM pm.ondemand process manager has a subtle bug in the way it uses edge-triggered polling (with
epoll() or kqueue()) that causes it not to notice when multiple requests arrive at the same time,
and thus not to fork the appropriate number of children to handle them. The bug was introduced
during pm.ondemand's initial development, when the author switched from level-triggered
select/poll to edge-triggered epoll/kqueue in order to a different bug that resulted in the fpm
parent process entering a cpu spin loop for brief periods when new requests arrived.
The details of the bug are too subtle to fully describe here. However, the PR I am about to submit
for this bug report contains a new DESIGN.md file that includes a thorough explanation.
Test script:
---------------
I do not know how to create a self-contained test case for this. However, using a custom
web-testing tool I wrote called Goofy (https://github.com/bjaspan/goofy), it is easy to reproduce.
The README file in that repo shows using Goofy to demonstrate the exact bug in FPM that I am
reporting here.
Expected result:
----------------
When N requests arrive nearly simultaneously, and FPM is allowed to fork N more processes, it should
fork N more processes.
Actual result:
--------------
When N requests arrive nearly simultaneously, and FPM is allowed to fork N more processes, it almost
always forks fewer than N processes, usually a lot fewer. The exact number depends on race
conditions with the fpm parent, children, epoll in the kernel, and who knows what else.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=69724&edit=1