Req #77959 [NEW]: Scheduling of PHP-FPM processes in "ondemand"

From: mp at webfactory dot de Operating system: Ubuntu 18.04.2 LTS PHP version: 7.2.17 Package: FPM related Bug Type: Feature/Change Request Bug description:Scheduling of PHP-FPM processes in "ondemand" Description: ------------ I am using PHP-FPM with the "ondemand" process model, and pm.max_requests = 500 pm.process_timeout = 120 pm.max_children = 50 (If the exact reasoning why I am using this process model or these numbers matters, let me know and I'll amend the bug description.) From time to time, my server faces load spikes that can lead to a few dozen PHP-FPM processes running simultaneously. The baseline load is about 2 PHP-FPM reqs/s. What I have observed is that after the spikes, I have a large number of FPM processes that never go away. I would have expected that some time after handling a load spike, the number of running processes should be very low, around what is needed to work the baseline load. I think the explanation is that PHP-FPM allocates work to worker processes in a round-robin fashion. Thus, every single running process gets something to do before the 120s timeout is reached. This is supported by the fact that on the status page, the number of requests processed is roughly the same for all children. I still have no clue why the max_requests does not seem to help. After some time, all the processes should have served the 500 requests an be terminated. Unless a replacement is started immediately (regardless of load), this should make the number of running (but idle) processes return to "a few". So, my request is: - Can anybody confirm processes are scheduled round-robin? - When max_requests is reached, is a replacement process launched immediately, or is it up to the process management model to launch a replacement when it sees fit? - Would it be possible to change the scheduling model to "use the oldest or youngest idle child" without severely impacting scheduling performance? -- Edit bug report at https://bugs.php.net/bug.php?id=77959&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=77959&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=77959&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=77959&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=77959&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=77959&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=77959&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=77959&r=needscript Try newer version: https://bugs.php.net/fix.php?id=77959&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=77959&r=support Expected behavior: https://bugs.php.net/fix.php?id=77959&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=77959&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=77959&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=77959&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=77959&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=77959&r=dst IIS Stability: https://bugs.php.net/fix.php?id=77959&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=77959&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=77959&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=77959&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=77959&r=mysqlcfg