0

I am trying to figure out why my apache processes are eating so much memory

My slice specs( 1.5GB RAM, CentOS 5, Apache2, PHP 5.2, MySQL)

As you can see my top processes are consuming nearly half of my entire memory and when more processes are spawned the server nearly grinds to a halt, frequently going over into swap and crashing.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6817 apache 40 0 296m 103m 3920 S 0.0 6.7 0:03.52 httpd 6789 apache 40 0 295m 101m 3932 S 0.0 6.6 0:07.04 httpd 6765 apache 40 0 284m 91m 3948 S 55.1 5.9 0:12.45 httpd 6798 apache 40 0 284m 90m 3944 S 0.0 5.9 0:05.49 httpd 6542 apache 40 0 283m 90m 3956 S 0.0 5.8 0:43.25 httpd 6827 apache 40 0 283m 88m 3796 S 0.0 5.7 0:01.83 httpd 

Does anyone have any clue what could be causing apache (and php) to be consuming so much memory?

 total used free shared buffers cached Mem: 1545 827 718 0 3 111 -/+ buffers/cache: 713 832 Swap: 3071 103 2968 

5 Answers 5

2

You're almost certainly running mod_php, which means you're almost certainly running apache in mpm_prefork.

If performance is generally okay until load causes you to start swapping, a quick fix is to start throttling down apache's MaxClients. If apache is allowed to fork worker processes whenever it wants, it's going to start swapping under load. Requests will queue until a worker is available, so things can get slow, but not as slow as the death-by-swap.

If you really need to tune things tighter, consider getting away from prefork apache mpm. That means running PHP as FastCGI. If you're going to go with PHP under FastCGI, you should consider upgrading to PHP 5.3.3, which has much nicer FastCGI process manager (--enable-fpm configure option).

php-fpm/worker is much more memory efficient than old-fashioned mod_php. You can then tune the number of apache processes/threads independently of the number of PHP processes. And your memory-heavy PHP processes are only used for serving up php-driven content, and not wasted on serving static files.

1
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6817 apache 40 0 296m 103m 3920 S 0.0 6.7 0:03.52 httpd 6789 apache 40 0 295m 101m 3932 S 0.0 6.6 0:07.04 httpd 6765 apache 40 0 284m 91m 3948 S 55.1 5.9 0:12.45 httpd 6798 apache 40 0 284m 90m 3944 S 0.0 5.9 0:05.49 httpd 6542 apache 40 0 283m 90m 3956 S 0.0 5.8 0:43.25 httpd 6827 apache 40 0 283m 88m 3796 S 0.0 5.7 0:01.83 httpd 

Is wordpress the only thing running on apache? I'm curious mostly about the very high cpu usage of PID 6765 there. Wonder what it is doing. As far as the mem%s go, that looks pretty normal for a webapp setup, as each thread is actually running more than one worker.

What MPM are you using for apache, and how do you have it configured?

Also, if you're posting terminal dumps, please start each line with four spaces. It allows formatting to be preserved.

1

My crystal ball is a bit dusty, but I guess you are using memcached and its PHP extension. If that's the case, try to disable it unless you really need the thing.

Another possibility is that you have some kind of op-code cache, such as XCache, installed, and have configured it to use a lot of memory.

You may try

pmap -x `pidof apache` 

to see what's consuming the memory.

1

Memory figures for apache processes are pretty normal for a PHP setup. An highly tuned apache/php server here with many modules/extensions not loaded or even compiled usually runs between 200 and 350MiB of virtual memory per process, and 40~45MiB of resident memory per process.

You probably are not that familiar with the virtual memory subsystem? From what you're writing, your system is probably healty. Check the load average, you're ok with those memory figures unless that also goes high.

If you think it should stay forever at 0MiB swap, you're thinking wrong, that would be a really stupid thing for your operating system to do.

1

Dont load unused apache modules (like python, perl, etc).

Use eAccelerator php module. It is php compiler. You can get faster execution and smaller memory usage.

Other users maybe also right.

You must log in to answer this question.