2

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?

1 Answer 1

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.

3
  • Which doesnt actually answer the question of what the overhead is..
    – Shayne
    Jun 22, 2022 at 8:23
  • The actual overhead is hard to quantify of course, but ondemad may make any overhead irrelevant. That comment is from 9 years ago and I'm still running ~350 separate pools per server efficiently with pm=ondemand
    – Nick
    Jun 23, 2022 at 16:55
  • Which doesnt answer the question of what the overhead is.
    – Shayne
    Jun 24, 2022 at 6:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .