Just dealt with a server swamping with PHP-FPM child processes. The ‘pm.max_children’ was set to 9999 by default in all PHP-FPM pools. The default PHP-FPM settings are unreasonable and can’t find a global way to fix them. The sample config setting is pm.max_children = 5 but Virtualmin used pm.max_children = 9999.
I can’t see any global way to fix this, unless adding it to ‘Additional FPM pool options’ will override the default pool setting? Or is there a template somewhere to edit? I can’t find any setting for this at the per-site level either. Though you can ‘manually edit config’ under Services → PHP-FPM options to change it. Ideally there would get a sensible starting default value and a global way to change/limit that.
Yes, there is a template (Server Templates->PHP Options, probably).
But, also, this is a bug. That’s nonsensically high. I’m not sure where the 9999 comes from, but it should never be that high. Reasonable numbers are in the tens (based on RAM, as I understand it), not thousands.
@Jamie can pm.max_children be made more reasonable by default? Something like 10 or 20?
No, that only provides templates for the php.ini file not for the PFM pool file. There is a Additional FPM pool options setting though, and I’m wondering if that gets added to the end of the pool config file if that could override the the built in 9999 default.
If it came to that I was just going to use sed but that’s a great Web UI tip
Cool. Any plausible/reasonable default is fine. I think more people would be rolling with 5-20 than people who would genuinely want 30% of the process ID space used by every site Maybe the same default as the FCGI sub-processes - which is roughly the same thing? That defaults to 20 I think and is changeable in Server Configuration -> PHP Options.
Ideally this FPM pool value would be one of the settings or part of an editable template under Server Templates -> PHP Options or Virtualmin Configuration -> PHP Options at the global/default/template level, and then one of the Services -> PHP-FPM Configuration -> Resource Limits at the site level.
Given HTTP/2 is > 50% of all traffic now and HTTP/3 is coming, the days when we can use anything other than FPM are numbered. The old CGI/FCGI stuff should be deprecated and eventually removed IMO.
Totally understand about push-back. That’s why I said deprecate rather than remove any time soon. I’d mostly like to see the default, OOB install be a modern configuration. And the legacy, anti-pattern tools to be optional installs with ‘educational’ banners/messages on the setting dialogs. Maybe a subtle red color for the legacy menu items just to feel ominous.
Changing the defaults for 7 would go a long way. Right now it is actually a bit tricky to convert a 6.x install to support HTTP/2. Get it working and work our what to (safely) remove. And there’s a few rough edge with FPM site conversions and updates. I’d prefer to see FPM use named sockets owned by the site account in the rather than port numbers from the shared server pool, with all the security and renumbering issues that brings.
If you start with 7 supports HTTP/2 HTTP/3 OOB, then a lot of things work backwards from that. You want to enable X old bad thing? We’d love to, but you know you’ll have to go disable HTTP/2 for that, oh btw HTTP/1.1 will make your performance suck, “proceed yes or no?”.
Jamie, ideally this value should be calculated based on the amount of RAM available. We could also tie it to post-configuration wizard, where you define how databases are used (Small, Medium, Large, Huge).
The database server cannot be configured on a per virtual server basis (well, maybe it can, but…) however the PHP-FPM pool makes it easy to configure each virtual server to receive only an allotted number of child processes. If this could be tied in with Account Plans or Server Templates then wow - I could charge a premium from the owner of that WordPress site which has Elementor installed with a zillion addons.