Re: excessive amounts of consumed memory (RSS), triggering OOM killer - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: excessive amounts of consumed memory (RSS), triggering OOM killer
Date
Msg-id 1f996e3854e8eee421dec54d6f066e0d.squirrel@2.emaily.eu
Whole thread Raw
In response to Re: excessive amounts of consumed memory (RSS), triggering OOM killer  (Tomas Vondra <tv@fuzzy.cz>)
List pgsql-hackers
Dne 2 Prosinec 2014, 10:59, Tomas Vondra napsal(a):
> Dne 2014-12-02 02:52, Tom Lane napsal:
>> Tomas Vondra <tv@fuzzy.cz> writes:
>>
>>> Also, this explains the TopMemoryContext size, but not the RSS size
>>> (or am I missing something)?
>>
>> Very possibly you're left with "islands" that prevent reclaiming very
>> much of the peak RAM usage.  It'd be hard to be sure without some sort
>> of memory map, of course.
>
> Yes, that's something I was thinking about too - I believe what happens
> is that allocations of info in TopMemoryContext and the actual contexts
> are interleaved, and at the end only the memory contexts are deleted.
> The blocks allocated in TopMemoryContexts are kept, creating the
> "islands".
>
> If that's the case, allocating the child context info within the parent
> context would solve this, because these pieces would be reclaimed with
> the rest of the parent memory.

On second thought, I'm not sure this explains the continuous increase of
consumed memory. When the first iteration consumes 2,818g of memory, why
should the following iterations consume significantly more? The allocation
patterns should be (almost) exactly the same, reusing the already
allocated memory (either at the system or TopMemoryContext level).

regards
Tomas




pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation
Next
From: Andres Freund
Date:
Subject: pg_stat_statement normalization fails due to temporary tables