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

I am running the following on a Dell R610 (Quad core & 12GB RAM): Red Hat Enterprise Linux Server release 5.5 httpd 2.2.3 PHP 5.1.6

The web application running on this server is randomly leaking memory. Since the application is fairly big I have spent today trying to come up with a way to profile or trace the culprit script. The best tool I have so far is strace using strace -p PID -tt -o trace4.log -s 256. Unfortunately the memory usage can jump from 20m to 791m in a matter of seconds so running strace on the culprit process does not yield anything useful.

I tried starting httpd using strace strace -f -o trace_all.log /etc/init.d/httpd start, but unfortunately this causes extreme lag and unresponsiveness since the site receives fairly high traffic.

I understand that it is not best practice to debug in the production environment, but I am trying to narrow down what page and/or script is causing this issue and have been unable to replicate the problem when testing in the development environment

Any suggestions would be greatly appreciated.

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Another, less intrusive way, to get an idea of where the memory is going is to run pmap. Running pmap -x will dump out a list of all the memory allocated to the process. It's broken down by memory address and includes size of the allocation, whether the memory is private to this process or shared, and a mapping as to what is being used by that memory (shared library/stack).

share|improve this answer
    
pmap shows me a large block of anon memory at ~263M. From my research this is usually heap data. I need to know what it is or how it got there. Any further thoughts? –  Robin Dec 1 '10 at 16:43
    
-anon- memory is anything that has been malloc'd by the program. The one thing you can be sure of is that the software requesting that large contiguous block of memory for some reason. To get any deeper, you'd need to follow up with something like gdb that would allow you to examine the memory addresses directly. It's still often useful to know for troubleshooting that the software is requesting a giant block of memory rather than several thousand smaller sets (that could point to things like too many threads). You may be able to correlate this with what you've seen in strace as well. –  Brian Dec 1 '10 at 21:00

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.