I encountered this problem when I first started working with Passenger, and have run into it repeatedly over the last year, so I thought I’d just throw out the fix I have for it.
Usually people having these problems are usually running the prefork MPM and have a section in their apache config file that looks like this
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
#Aside: To find out if what multi processing module (mpm) you are runing (worker or prefork) just run this command.
(it may also be httpd/httpd2/apache/apache2ctl/apachectl -l)
The apache processes themselves don’t usually take up a lot of memory, I’ve seen anywhere from 0.2MB – 14MB … but they usually lie in the range of 2 – 6MB.
The problem comes if you get a traffic spike and Apache spawns up to 150 process to handle the traffic.
You can see that you can easily have 300MB – 1GB of memory allocated to the processes and, consequently, run out of memory so that your server is now unresponsive.
The fix for this is to set MaxClients to, at minimum, your StartServers + Min Spare Servers. But you also want to take into consideration the Max Instances of your app that you’ve set for passenger and how many requests you want to be able to serve at a time.
From Apache documentation
MaxClients directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the
MaxClients limit will normally be queued, up to a number based on the
ListenBacklog directive. Once a child process is freed at the end of a different request, the connection will then be serviced.
Be sure to increase this number if you are running php apps on your server as well.
Hope this helps.