Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a question. Over time, should an apache process's memory consumption grow? I am wondering if this is normal apache behavior or we may be causing this somehow in code?

Basically, we have a simple LAMP stack running Drupal. On an apache restart the processes fire up @ 120MB and eventually all the processes climb to 500-1GB of memory(resident aka physical-non-swap).

This doesn't seem to be affected by time or actual server load either.

Any help is much appreciated, thanks!

share|improve this question

migrated from stackoverflow.com Oct 18 '12 at 5:29

This question came from our site for professional and enthusiast programmers.

    
Yes, it could grow if you are using some kind of cache or you have some script that uses a lot of memory to process. –  Zoredache Oct 23 '12 at 16:48

2 Answers 2

As a general rule Apache processes should not just grow for no discernible reason. If your Apache processes are really ballooning as they process requests and you can rule out caches and like Zoredache mentioned in his comment you may have a memory leak in some script that's being run.

Debugging memory leaks is left as an exercise for the reader - tools like valgrind may help.

share|improve this answer

no, apache memory cunsomption should not grow anormally as process childs are killed after a period. If your apache is eating your memory, you can tweak your apache configuration.

MaxRequestsPerChild 300

Timeout 15
KeepAlive On
MaxKeepAliveRequests 30
KeepAliveTimeout 3

remember that the more you reduce processes life, the fast will be your server but that will increase your cpu usage.

share|improve this answer
    
Apache processes are not always killed off after a period of time (MaxRequestsPerChild can be 0 -- unlimited -- or set high enough that your Apache processes pretty much live forever and can balloon in size). –  voretaq7 Oct 23 '12 at 17:15
    
the definite solution here is adding right rules to iptables. With script kiddies, any server will be down easily, a simple ping of death is enought even if apache is well configured. stevekrzysiak needs to hire someone... –  Julio Fong Nov 4 '12 at 13:05
    
I don't see how adding firewall rules would help here. Blocking things at the firewall only work if the server is actually under attack, and (b) you can localize the attack such that effective firewall rules can be written to block it. There is nothing in the question that leads me to believe this is an attack of any kind: Badly written code on the server that leaks memory under benign conditions seems more likely. (Of course dropping all HTTP traffic would mitigate this problem, but it has the undesirable side effect of taking down the site...) –  voretaq7 Nov 5 '12 at 19:06
    
any server is in constant attack. Ports scanning, spoofing, bad bots. Apache users can grow by 10 to 50 in a few minutes, if no firewall rule is set at all, apache will open a new connection for bots. I remenbered that I had a 512mb vps and it crashed every day with a wordpress site on it and no visitor at all. This is a common problem as usually vps are sold on an insecure network constantly scanned by bots. –  Julio Fong Nov 7 '12 at 14:42
    
I'm sorry Julio, but I don't agree - First, if a server is leaking memory there is a programming problem, that needs to be solved - Address the root cause rather than throwing band-aids on a severed arm. Second, a server should be adequately sized to handle its load, including the normal background noise of bots and scanning. A firewall would have zero value here unless the OP could specifically enumerate every host allowed to access the system (or they blocked all traffic, in which case shutting down the web server is a better solution...) –  voretaq7 Nov 7 '12 at 18:38

Your Answer

 
discard

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.