Debugging memory leaks in IHS

Provide feedback on the IBM HTTP Server forum on IBM developerWorks.

Known issue to check for

What to look for

If a growth of both RSS and VSZ can be demonstrated, it's important to verify that the memory usage never flattens out after many tens of thousands of hits. Any report of a memory leak must show both RSS and VSZ, for a fixed set of processes, over time.

Short term relief

Identifying a culprit

The following steps are required to help suppport identify the cause of a memory leak. When opening a PMR, be sure to illustrate which (if any) of the diagnostic steps have been taken and their impact on the symptom.

mod_memuse

mod_memuse is a server module that identifies requests during which the total server memory use increased. Usage:

  1. Edit configuration to load the module:
    LoadModule memuse_module path/to/mod_memuse.so
  2. Add %{MEMUSE}e to the access log format:
    LogFormat "%h %l %u %t \"%r\" %>s %b %{MEMUSE}e" common
  3. Start the server and recreate the problem. Access log entries will look like:
    127.0.0.1 - - [26/Jan/2011:09:01:23 -0500] "GET /index.html HTTP/1.1" 200 23 M1284:5a2
    127.0.0.1 - - [26/Jan/2011:09:01:23 -0500] "GET /index.html HTTP/1.1" 200 23 -
    
    where "M1284:5a2" means that the child process with pid 1284 increased by 0x5a2 bytes during the processing of that request, while "-" means the total process memory usage did not change during that request.

Note that this shows that the total process memory usage increased while the server was processing that request, but not necessarily that that request caused the increase.

To identify which requests tend to trigger increases in memory usage, perform the following steps: