I am currently looking at a core of a httpd 2.4 process using the event MPM that consumed a lot of memory (core dump file size about 1.4 GB). While taking the core actually no request was processed by this process. I suspect a memory leak in a 3rd party closed source module. As I have no view in the 3rd party module I tried to find out the heap memory usage of httpd and the included modules.
For this I used the new dump_pool_and_children I added to .gdbinit which delivers me the memory used by all pools below 'apr_global_pool' and the amount of memory in the allocator free lists associated to these pools. This delivered a usage of only a few MB. Of course I am aware that the process consumes additional memory for stack, static data and text segments, but this usage should be static. Is there any heap usage by httpd that I could have missed? - We do not use the unmanaged pools from APR. So I should have caught all pools. - I do no think that we use allocators that are not used by a pool. Hence I should have caught all allocators and its free lists. - As no request was processed when I captured the core (all worker threads were waiting for work) I doubt that missed any or at least large memory consuming buckets. So possible other consumers of memory apart from the 3rd party module that come to my mind: - Could any of the glibc (httpd was running on a Linux system) functions wrapped by APR consume a lot of memory? - As far as I researched glibc by default should return memory to the OS if more then 128 KB are free at the top of the heap. Regards Rüdiger
