Re: excessive amounts of consumed memory (RSS), triggering OOM killer

From: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
To: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: excessive amounts of consumed memory (RSS), triggering OOM killer
Date: 2014-12-02 11:22:13
Message-ID: 1f996e3854e8eee421dec54d6f066e0d.squirrel@2.emaily.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dne 2 Prosinec 2014, 10:59, Tomas Vondra napsal(a):
> Dne 2014-12-02 02:52, Tom Lane napsal:
>> Tomas Vondra <tv(at)fuzzy(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-12-02 13:07:20 pg_stat_statement normalization fails due to temporary tables
Previous Message Воронин Дмитрий 2014-12-02 11:00:12 Getting references for OID