Limit PHP Processes per Domain

Is it possible to limit the total number of PHP processes per domain in Virtualmin? If so, how is this done?

One of our hosted sites is getting slammed with activity, and it is spawning several hundred php-cgi processes (using FastCGI / php5.fcgi) at a time. This activity is sucking up all available memory and CPU, which is preventing access to all other sites and services on the server. What can we do in this situation?

FYI, I am aware of the option to set the "PHP FCGId sub-processes" (default of 4), but I want to limit the total number that can be spawned for a single domain. For example, under Server Owner Limits, there is an option for "Maximum Mongrel server processes for Rails", but I do not see any options for PHP FCGId.


FYI, I have opened up an RFE for this issue in the bug tracker:

FS#3850 - RFE: Server Resource Limits

I didn’t receive any responses to my initial post here, but I feel this issue is too important (and too easy to fix) to ignore.


Alan, if you’re using mod_fcgid, you should be able to do that. The process limits in mod_fcgid are rock solid in my experience. The mod_fcgid directives for this is DefaultMaxClassProcessCount, and actually applies on a per virtual host basis (Apache wise).

The thing to avoid though is to use PHP’s own dynamic spawning (which I fear is Virtualmin’s default). If you see any mention of ‘PHP_FCGI_CHILDREN’ in your PHP wrapper scripts (php5.fcgi), remove those lines. If you do have them there, you’re actually using two layers of dynamic spawning - mod_fcgid and PHP. PHP’s native spawning sucks big time (basically - it fires up the maximum processes allowed (as per PHP_FCGI_CHILDREN) no matter what kind of traffic comes in, so you’re wasting a lot of memory.

There is a config option in VMPro to define a custom PHP wrapper (Jamie implemented that on my request) so you can get rid of those for new virtual servers too. I’ve seen sites getting hammered by spammers, but mod_fcgid stayed solid and didn’t yield an inch.

The thing to avoid though is to use PHP's own dynamic spawning (which I fear is Virtualmin's default).

Not in the next release. It got added at customer request a while back, and it took a while for it to become apparent that it’s not the right choice here.

i’ve been suffering from fork bombs lately, so i stumbled across this thread that, i hope, will help me to solve the problem.
ok so my /etc/apache2/mods-enabled/fcgid.conf now looks like this

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  IPCConnectTimeout 120
  IPCCommTimeout 120
  DefaultMaxClassProcessCount 5

so basically i added DefaultMaxClassProcessCount 5 to the file.
now, in all /home/*/fcgi-bin/php5.fcgi i have

ulimit -t 3600
export PHPRC
umask 022
exec /usr/bin/php5-cgi

so PHP_FCGI_CHILDREN as you can see is there.
is this correct or should that be removed?
also, why is that php5.fcgi file also in /home/*/public_html/ ?


Another option as well would be to go into Administration Options -> Edit Resource Limits, and to set “Max Number of Processes” for any Virtual Servers you’d like to have limits for.


yes, i actually wanted to start a thread about that… cause i want to set the limits there, but i find nowhere in the docs or whatever what some sane values would be.
i plan to set different limits depending on the server plan, so what would be an example for small websites and one for more trafficated websites?
what does count as process there anyway, besides the web server?
i really wat to know what i’m doing before setting any limits to anyone…

It refers to processes owned by a given user that may run at any point in time.

It’s difficult to give any specific numbers, but my suggestion would be to take a peek at your current process list, see how many processes are owned by certain users at any given time, and work on some numbers based on that.

All it does is set /etc/security/limits.conf.

Those limits aren’t particularly graceful, I tend to view them, at best, as a way to keep users from accidentally using all the resources on the system.


thanks dude, will try that on sunday, depending on how many beers i will get on saturday.