Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: httpd memory consumption
To: dev@httpd.apache.org
References: <06a0b5ba-aa10-7352-d08d-5856abd077a7@apache.org>
 <5C474035-17D4-42C3-AC75-7DBDFB2E08A8@greenbytes.de>
From: Ruediger Pluem <rpluem@apache.org>
Message-ID: <41555764-adf1-5c25-6152-37a5117c1cac@apache.org>
Date: Fri, 6 Oct 2017 10:01:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:49.0) Gecko/20100101
 Firefox/49.0 SeaMonkey/2.46
MIME-Version: 1.0
In-Reply-To: <5C474035-17D4-42C3-AC75-7DBDFB2E08A8@greenbytes.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
archived-at: Fri, 06 Oct 2017 08:01:49 -0000


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 <rpluem@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
> 
>