Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

I am curious how Apache handles how memory is allocated to each of the processes that it creates. I am currently running a Debian server.

Right now my server has 8GB of memory and has been on for about 7 days right now. Right now it shows that my server has about 50MB of available memory.

When I run "top -u www-data" I see all the Apache processes that are currently running. In the VIRT column I am seeing that each process is at 354m and the RES column varies between 9254 and 60m.

What I find odd is that when I restart Apache, the process IDs do change, but they automatically go right back to taking up about the same amount of memory.

Basically my concern is that Apache is taking up too much memory. Right now I have MaxKeepAliveRequests set to 100 and KeepAliveTimeout set to 3. I also have the following directives set:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   200

<IfModule mpm_worker_module>
    StartServers          2
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0

Now when I access the server, I do not really see any performance issues. The load average generally stays very long, I just seem to be having pretty low amount of available memory. It is not going to swap hardly at all (760k is the highest I have seen it).

I just seem to be worrying that Apache is taking too much memory. If this is normal and it will not cause the server to kill itself, I can learn to live with this. It just does not seem right.

Any input would be greatly appreciated. Thanks

Josh Pennington

share|improve this question
up vote 2 down vote accepted

The VIRT size isn't very useful. It includes all sorts of mapped memory pages that aren't really in use. Look at RES instead. RES minus SHR is closer to your actual per-process memory footprint.

The RES of 60m on some processes is a little higher than I'd expect. Are you using any modules (mod_perl, mod_php, mod_python) that are likely to allocate a lot of memory?

share|improve this answer
I am running PHP on the server. I think it is mod_php (If that is the pretty standard way of doing it at least -- I am still a little green when it comes to Apache/Linux administration). With the revelation that the actual memory footprint it RES minus SHR I may have to look elsewhere as to where the memory on the server is going since that number is actually about 10% of what I thought was actually being used (actually using 40M when I originally thought 400M). Do you know the best way to find memory hogging programs? Thanks much for your help! – Josh Pennington Aug 16 '10 at 21:23
top and then "M" to sort by memory does a pretty good job of showing you where memory is going. vmstat 5 5 is also good to get a picture of what's actually going on. – freiheit Aug 16 '10 at 21:26

Do you know which module you're using? mpm_worker_module or mpm_prefork_module? With either of them, you can tune down the number StartServers and MinSpareServers/MinSpareThreads. This will lower the initial amount of resources that Apache consumes on startup. As traffic increases though, Apache will continue to fork/spawn off additional process/threads to handle the load and the resources will go up.

Also, ignore how much "free" memory your server has. If Linux find free memory, it will use it for caching data from your disks as well as act as buffers. If you have a large amount of data in 'Cached', then your system is running fine. If it needs more memory for actual processes, you'll find that Linux will purge some of the memory from Cached and give it to the process in need.

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.