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