Bug #69724 [Com]: pm.ondemand forks fewer child workers than it should

Edit report at https://bugs.php.net/bug.php?id=69724&edit=1 ID: 69724 Comment by: justinpor119 at gmail dot com Reported by: barry at jaspan dot org Summary: pm.ondemand forks fewer child workers than it should Status: Open Type: Bug Package: FPM related Operating System: Linux PHP Version: 5.5.25 Block user comment: N Private report: N New Comment: You have more request coming in than you have workers available to handle the requests. The request will be queued until a worker becomes available to handle the request. Reason for this is that your pm.max_children is set too low, i.e. you have more requests than the number of workers can handle https://www.upsers.mobi/ 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