Feature #2431
closedmod_cgi process limit
Description
When requests arrive faster than a cgi script can process them, lots of processes are created. The effect on the system is similar to a fork bomb. When using ulimit lighttpd locks up and does not process any requests until restarted.
It will be nice if there is a configuration option "maximum number of cgi processes".
Updated by stbuehler over 12 years ago
- Target version set to 1.4.x
It would probably be better to just kill mod_cgi...
mod_cgi has some serious drawbacks, iirc it blocks while writing the request data to the cgi process in 1.4.
I recommend the fcgi-cgi wrapper - it looks like FastCGI to lighty, and can execute cgi programs. run it as a separate user, and use ulimit for it.
Updated by gstrauss over 8 years ago
- Status changed from New to Fixed
- Target version changed from 1.4.x to 1.4.40
Recent commits change mod_cgi to asynchronously send request body to CGI script, and to be able to read CGI response prior to sending request body to CGI, i.e. mod_cgi no longer blocks with the bad behavior you describe above. (However, a thrashing box is a thrashing box, and lighttpd will not be responsive if the box is thrashing.)
Regarding your feature request, a global "number of CGI" limit does not seem like a good solution since some scripts might respond much more quickly than other scripts. There are many, many, many different ways to approach availability of service, and there is no one-size-fits-all solution.
@stbuehler recommended one option: the fcgi-cgi wrapper - it looks like FastCGI to lighty, and can execute cgi programs. run it as a separate user, and use ulimit for it.
Another option now available to you (with lighttpd 1.4.40) is for your heavy-weight script (or a wrapper script in front of your heavy-weight script) to manage the number of outstanding connections, and immediately returning a 503 Service Unavailable if the load average is too high, service times too long, or any other metric you deem applicable and can measure.
And, of course, there are many other options, too numerous to list here, and many more or less advantageous depending on your specific use-case.
Updated by gstrauss over 8 years ago
(If looking to arbitrarily limit the number of outstanding requests to backends, perhaps a more generic solution would be to write a module to allow URI paths to apply limits to number of outstanding requests waiting for backends for that URI path, and could return 503 Service Unavailable for any new requests to such a URI path comes in while the limit has been reached)
Updated by gstrauss over 8 years ago
- Related to Feature #967: request-queue-limit option for mod_fastcgi added
Updated by gstrauss almost 8 years ago
- Related to Feature #1530: cgi.max_processes addition added
Also available in: Atom