WARNING: [pool www] server reached pm.max_children setting (1), consider raising it

[sfriesel]

This setting should be generally higher or be possible to configure.

[zerrvox]

What is the status of this? Seems to be a bit strict to only allow one.

[pst]

It's automatically raised with the container size. For size one containers, this warning still shows up.

[zerrvox]

I still get in on a size 3 container even with two application servers. I genuinely believe that the setting is too low, and a site with many small but fast request quickly will starve out apache. So I would prefer if it was configurable such that I don't have to make my own buildpack to change it.

[pst]

Do you get the same message (e.g. setting (1)) or does it say 3 there now? How much traffic did you send to those two size 3 containers? Any information you can share helps to better understand and hopefully fix this.

[zerrvox]

It says 3 in the error message now. After having looked a bit more into it I can see I get it when I make a single request on our staging page in development mode, where assets are not minified and combined. Resulting in something like 80 requests within a couple of seconds. This is mostly static files and the response is therefore fast for most request.

I know this might not be the most common scenario as it only happens on first page load and in production it will be a lot fewer requests, but then again if a single page request can starve the apache connection pool, how will it fare with many concurrent users even in a more optimized setup.

[pst]

This is not the Apache connection pool. This is the max number of php-fpm children. Static requests are answered by Apache directly, this should only affect dynamic requests. Or ones that end up in PHP due to a catch-all .htaccess rule or similar.

The max_clients for Apache are (container size + 1) * 8.

See: https://github.com/cloudControl/buildpack-php/blob/master/support/boot.sh

The PHP buildpack sets max_children to the size of the container. This means one child per 128mb of RAM.

See: https://github.com/cloudControl/buildpack-php/blob/master/conf/php-fpm.ini

Now it's still a valid discussion what this number should be set to. But it does not necessarily make a lot of sense to put more than one child per 128mb. Only in special cases maybe. Even for applications with a low memory footprint it's usually the much better approach to scale out to a lot of small containers. Because each container gets put on a different host this means additional CPU cores and distributed across the three availability zones this gives a great availability improvement.

[vervas]

https://github.com/cloudControl/buildpack-php#php-fpm
#16

[sgotre]

I agree, it is not a good idea to use this value to 'scale' an app, more containers are definitely a more reliable way to achieve good results. But allowing more than one process on each container might be a good way to catch traffic peaks on certain low-memory apps.

Lets' say we have 12 Containers running (4 in each availability zone) each having 128 MB RAM.
And we have an app with a low-memory footprint of about 30 MB according to New Relic.

By standard configuration we would only have 12 processes available.

If I would like to increase this to a maximum of 3 processes on each container. What do I have to set the pm.max_children to?

Is this value set on a per container basis, therefore: 12 processes on each container. Or is it set for the whole app: Maximum 12 processes on all containers?

[pst]

The buildpack writes the config file during the push into the image. Each container then is started from this same image. So all values are per container.