Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm migrating the configuration of a webserver that runs PHP applications using PHP-FPM behind nginx. The server has about 40-50 (and growing) vhosts on it. The server is a single CPU VM with 1GB of ram. Although this isn't a large amount of resources to play with, I do have many of these behind a load balancer, preferring to scale horizontally rather than vertically.

The previous configuration had all vhosts running out of a single PHP-FPM pool, running under the same user. Max-children was around 20, and the server appeared to cope with the load thrown at it (in total, around 100,000 hits per day - not mega traffic).

Thinking about segregation of these sites, I'm considering moving to a model where each vhost has its own PHP-FPM pool running under a specific user for that site, and then chrooting that pool to the docroot of the vhost. However, even on conservative pool children settings (initial=2), will yield nearly 100 FPM processes when idle.

My question is: is this going to cause a problem? Are there any inherent memory issues with spinning up this many processes?

Final bonus question: any ulimit hints for php-fpm if I do go down this approach?

share|improve this question

1 Answer 1

I've been looking at the same thing.

Turns out the solution is the ondemand process manager for FPM. Just set:

pm = ondemand

It allows 0 child FPM processes if there are no hits. They are created for each pool when the pool gets hits, and get closed down after a timeout.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.