Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

have a serious problem. I've got virtual server which runs Apache and two web project with a lot of visitors (about 5 hits per second). My server starts to shut down by itself. In error log I found this problem

[error] server reached MaxClients setting, consider raising the MaxClients setting
[notice] caught SIGTERM, shutting down

so I search for solution to raise these numbers. I discover that this number is in two section in apache confinguration. With

/usr/sbin/httpd -l
Compiled in modules:

I found that my server is using prefork. So I again search for proper values and tried these

<IfModule prefork.c>
    StartServers       8
    MinSpareServers    5
    MaxSpareServers   20
    ServerLimit     1024
    MaxClients      1024
    MaxRequestsPerChild  4000

but server still shuts down even with these values. Can anybody guide me where to look, what to read, or what to set for proper stable run of server? I will appreciate any help, folks.

The server runs Linux CentOS 5.4

Thx beny

share|improve this question

Since your server is running prefork mode, this means that each connection gets its own process - so first of all check to see whether there are 1024 or so httpd processes running on the system.

To get a better handle on what your server is doing you may want to enable the server-status page.

LoadModule status_module modules/

ExtendedStatus On

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from

This will then allow you to view the state of connections to your server and try to figure out just what's causing all the connections to be consumed.

My suspicion is the possibility of some kind of rogue proxy or rewrite statement which is causing the server to continually loop its connections within itself until all of them are consumed.

share|improve this answer
As DaveG noted, locate and resolve the root cause (Look in your logs to see what's so popular - didjya get slashdotted?). 1024 apache processes are a lot of simultaneous connections for most sites (If that's really not enough you probably need to start looking in to load balancing) – voretaq7 Feb 9 '10 at 15:51

Maybe your server has KeepAlive feature turned on and insanely high value for KeepAliveTimeOut?

This could generate a bunch of inactive connections waiting too much time to shut down, ending up in a server crunch.

Check into your apache configuration and/or into virtualhost definitions.


share|improve this answer

Before upping the number again, you can do a few things to lower the amount of processes Apache spawns.

Enable keepalive and set an aggresively low timeout for it:

KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 5

All requests from the same client will be handled via a single TCP connection to the server. The low KeepAliveTimeout value means Apache will kill off the KeepAlive connection quickly, so as long as the client does not leave a communication pause beyond 5 seconds the client can make use of only a single connection for the whole page load.

Also, lower your max requests per child to something like 1000. Apache processes often grow in memory use with each request, so lowering the max requests will ultimately lower the overall memory usage for a given amount of httpd processes.

Lastly, as was stated previously, you should watch the server during it's busiest hour using TOP or the ps command. Find out how many apache processes are being spawned and how much memory each is consuming. Then you can calculate a proper Max Clients based off the servers available ram and per process memory usage.

If you continue to see issues after these tweaks you may want to look into moving away from Apache's default prefork module and use the worker mpm module instead. This will require using fastcgi or something similar for handling php requests; ultimately though that's a good idea in its own right.

cough nginx cough ;)

share|improve this answer

Your Answer


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.