On 10/06/2017 09:56 AM, Stefan Eissing wrote: > Were many threads spawned? Asking for a friend...
17 by httpd and 12 by the 3rd party module. Additional information: no mod_http2 loaded :-) Regards Rüdiger > >> Am 06.10.2017 um 09:46 schrieb Ruediger Pluem <rpl...@apache.org>: >> >> 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 > >
