Re: BUG #16707: Memory leak

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kurt Roeckx <kurt(at)roeckx(dot)be>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16707: Memory leak
Date: 2020-11-10 04:31:27
Message-ID: 20201110043127.sfkyvvjqy7x3er5k@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2020-11-09 17:20:37 -0500, Tom Lane wrote:
> Kurt Roeckx <kurt(at)roeckx(dot)be> writes:
> > Grand total: 3575000 bytes in 533 blocks; 596232 free (450 chunks); 2978768 used
>
> > Which was for this process:
> > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> > postgres 10000 2.6 16.3 5547172 5374656 ? Ss Nov08 54:10 postgres: synapse synapse [local] idle
>
> Hm. It would seem that whatever you're leaking was not allocated via
> palloc. Have you got any extensions loaded into that backend?
>
> It's also worth noting that if you've got 4GB of shared buffers,
> a total process vsize of 5.3GB doesn't seem all that far out of
> line. I'm not quite convinced that you have a leak at all,
> as opposed to processes gradually touching more and more of the
> shared buffer arena.

As this is on a halfway recent linux, I suggest doing something like

$ grep ^Rss /proc/$pid/status
RssAnon: 6664 kB
RssFile: 69512 kB
RssShmem: 15788 kB

Anon are allocations and some other small stuff, RssFile is memory
mapped files, shmem is shared memory (but 0 when huge pages are used).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2020-11-10 05:48:02 Re: BUG #16696: Backend crash in llvmjit
Previous Message Andres Freund 2020-11-10 04:25:24 Re: BUG #16706: insert into on conflict(pk) do update error violates not-null constraint