Re: Out of Memory errors are frustrating as heck!

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gunther <raj(at)gusw(dot)net>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Subject: Re: Out of Memory errors are frustrating as heck!
Date: 2019-04-16 03:03:55
Message-ID: 1095.1555383835@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Gunther <raj(at)gusw(dot)net> writes:
> So what I am wondering now, is there seems to be an EXPLOSION of memory
> consumption near the time of the crash. That ExecutorState has
> 2,238,648,944 but just until the very last second(s) the RES memory as
> per top was 1.5 GB I swear.

That's not hugely surprising really, especially in a complex query.
It could be performing some preliminary join that doesn't leak, and
then when it starts to perform the join that does have the leak,
kaboom. Also, given that you seem to be invoking multi-batch joins,
maybe the preliminary phase is fine and there's only a leak when
reading back a batch.

Anyway, the upshot is that you need to investigate what's happening
while the memory consumption is increasing. The behavior before
that starts to happen isn't going to be very interesting. It might
be a bit tricky to catch that if it only takes a few seconds to blow
up, but you could try "c 10000" or so to step through a lot of
AllocSetAlloc calls, repeating till the bad stuff starts to happen,
and then going back to looking at just where the calls are coming
from.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Gunther 2019-04-16 05:23:45 Re: Out of Memory errors are frustrating as heck!
Previous Message Tom Lane 2019-04-16 02:50:51 Re: Out of Memory errors are frustrating as heck!