PHP-FPM defaults to pm.max_children = 9999! How to globally set sane value for all existing virtual servers

Operating system: Ubuntu Linux
OS version: 18.04
Virtualmin: 6.15

Original 2017 issue highlighting this: PHP-FPM pm.max_children and control panel and server templates [#52223] | Virtualmin

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.

Refs for PHP-FPM settings issues:

https://www.virtualmin.com/node/54678#comment-811858

1 Like

Try this - I fixed over 200 virtual servers in under a minute.

5 Likes

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?

2 Likes

We’re using 9999 as a proxy for “unlimited” since there’s no actual unlimited option in the config.

I can lower it to 20 by default though.

2 Likes

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 :clap:

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 :smiley: 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.

See here: Virtualmin 7 checklist · Issue #42 · virtualmin/virtualmin-install · GitHub

But, we get a lot of pushback for changes like that. We still have folks enabling mod_php ten years after it made sense to do so.

1 Like

Thanks for the reference.

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. :smiley:

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?”. :smiley:

2 Likes

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).

2 Likes

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.

Just an idea… #FeatureRequest

5 Likes

I absolutely loath Elementor. It’s bloatware beyond the pale. Sadly, it’s tied into the most popular Wordpress template available: OceanWP.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

This issue is going to be solved with Virtualmin 7.2 release.

1 Like