Were many threads spawned? Asking for a friend...
> Am 06.10.2017 um 09:46 schrieb Ruediger Pluem <[email protected]>:
>
> 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
