php5-fpm uses too high value for pm.max_children by default

Bug #723480 reported by Marco Romeny
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
php
Unknown
Unknown
php5 (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: php5-fpm

The defaults in the file /etc/php5/fpm/pool.d/www.conf states a pm.max_children count of 50. Combined with php5's new max_memory default 128M, means a default installation would expect some 6GB of memory, something I'd love to run my cloud webserver off, but I think few do. Using php5-fpm-5.3.3-1ubuntu9.3 on Ubuntu 10.10
pm.max_children should probably be something like 4, with a note in the comments to increase if memory allows.

Revision history for this message
Patrick Domack (patrickdk) wrote :

I think 4 is alittle low, depending on what your doing, but 8-10 would be ok.

I agree, 50 is pretty high number to be using though.

Revision history for this message
Marco Romeny (marco-mimecom) wrote :

I am thinking that there will be many more virtual servers running in the wild very soon rather than physical servers, and I have a hunch that a lot of them are configured as 1Gb or even 512Mb -- if the defaults are too high, it results in a server that crashes after some time (it took mine about a day to crash) and at least for me it was not apparent where to find the error. I know, I should have done the math, but I somehow thought the defaults would be pre-calculated to fit a really small machine. In fact, one of my first errors I did, was to increase the limit to 100 children under that very assumption, and it definitely maxed my server out. It might even have been so that if I hadn't done that error I would have rebooted the server once a week and never found the problem.

I could blame this on php too: before 5.2.0 max_memory was 8Mb default, 5.2.0 it became 16Mb and then recently it jumped to 128Mb. That's a large step to take.

Now, I'm not sure if 128Mb for a php process is really necessary (although I know that wordpress loves memory), but in any case, I rather have a underutilized server by default than a server that slowly dives into dementia by default.

I even think 4 might be too many as the max_children if the minimum requirements for ubuntu server is listed at 256Mb. That number pretty much says "you can run most stuff comfortably with 512Mb"

As for if it's better to have many concurrent serving php instances vs a lot of memory allocated to each instance is probably depending an the application.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Hi Marco, thanks for taking the time to file this bug report.

There's a basic assumption I think that can be made, that servers have at least 1GB of virtual memory (not physical). 6GB, however, is excessive. Given that, I'm marking this bug as Confirmed. We'll need to open this discussion up with Debian before we can consider it Triaged.

Given the assumption of virtual memory, I think 6 would be a reasonable default, as this would leave 256MB for other daemons and FS cache, and only begin swapping when memory pressure is extreme. Ideally people would write PHP scripts that don't leak so badly as to use 128MB of RAM.

Since this one is subjective, I am setting the Importance to Low. I think the importance is still somewhat open to discussion, but we definitely should lower this default no matter what.

Changed in php5 (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Marco Romeny (marco-mimecom) wrote :

Sounds like a sound choice. And a sound assumption. I just looked at php-fpm from php's svn repo and the max_children is set as 50 there, so I'll try to log the same bug with php.

Revision history for this message
Marco Romeny (marco-mimecom) wrote :

Bug reported with php, so hopefully it won't be reintroduced if we fix it (that is if php fixes it).

Revision history for this message
Clint Byrum (clint-fewbar) wrote : Re: [Bug 723480] Re: php5-fpm uses too high value for pm.max_children by default

Marco, thanks for reporting it upstream! Can you please link that bug
here (and mention this bug there)? It will help to track the issue going
forward so we can drop any

On Fri, 2011-02-25 at 04:58 +0000, Marco Romeny wrote:
> Bug reported with php, so hopefully it won't be reintroduced if we fix
> it (that is if php fixes it).
>

Revision history for this message
Marco Romeny (marco-mimecom) wrote :

I mentioned and linked to this bug on that bug report, and here's the link to the bug in php's system:
http://bugs.php.net/bug.php?id=54098

I made a patch for their part (so easy with svn diff), but don't really know how to do it easily for binary packages (really, I guess I'm too lazy to go through installing all requirements and get the source packages etc.) Don't really want to have too much unnessecary stuff hanging around on my production server..

Revision history for this message
Thomas Ward (teward) wrote :

I believe this bug was fixed with the 5.3.6-11 version of the package (in Debian). This version of the package was a predecesor for the versions in Oneiric, Precise, Quantal, and Raring, and the default is now set to 5.

php5 (5.3.6-11) unstable; urgency=low

  * Use more reasonable default number of processes for PHP5-FPM
  * Enable firebird support everywhere also in debian/rules
  * Don't delete still used session files (Closes: #626640)
  * Enable building of php5-interbase by adding Architecture: any
    to debian/control
  * Use dh_prep instead of dh_clean -k

 -- Ondrej Surý <email address hidden> Sat, 14 May 2011 22:15:32 +0200

Changed in php5 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.