httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <>
Subject AW: httpd memory consumption
Date Mon, 09 Oct 2017 06:48:15 GMT

Von: William A Rowe Jr []
Gesendet: Samstag, 7. Oktober 2017 15:52
An: httpd <>
Betreff: Re: httpd memory consumption

Have you tried bisecting the config directives to see which is triggering the memory abuse?

Sounds like the module might not be async-ready, but should httpd really be doing many thread
swaps before the listener thread is tripped?

Does one of your modules load a large table al la Geo IP mapping?

Not that I am aware of.

Are you instantiating a scripting runtime, eg PHP or mod_perl?

Nothing like that.



On Oct 6, 2017 08:04, "Ruediger Pluem" <<>>

On 10/06/2017 10:26 AM, Bert Huijben wrote:
>> -----Original Message-----
>> From: Ruediger Pluem [<>]
>> Sent: vrijdag 6 oktober 2017 09:47
>> To: Apache HTTP Server Development List <<>>
>> Subject: httpd memory consumption
>> 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.
> Is APR configured to return memory to the OS? Otherwise you might just see all the allocated
memory in the free list of the pool allocator(s).

MaxMemFree is set to 2 MB in httpd and the allocator free list's that I have checked do not
contain much memory (around
400 KB in total for all of them).



View raw message