From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Kurt Roeckx <kurt(at)roeckx(dot)be> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16707: Memory leak |
Date: | 2020-11-10 19:35:17 |
Message-ID: | 20201110193517.t5hbqkya67gb23rq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On 2020-11-10 09:11:20 +0100, Kurt Roeckx wrote:
> On Mon, Nov 09, 2020 at 08:31:27PM -0800, Andres Freund wrote:
> > 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
>
> RssAnon: 1197064 kB
> RssFile: 27420 kB
> RssShmem: 4248052 kB
Ok, so it's actual allocations that are the problem. What kind of
queries is this workload running?
There's one known (slow) memory leak in the JIT code / LLVM. Could you
check if the issue vanishes if you disable JIT (jit = 0)?
Otherwise it might be useful to collect stack traces for memory
allocations. You could try something like 'heaptrack' or add a perf
probe on malloc, and do a perf profile.
E.g. something like
perf probe -x /lib/x86_64-linux-gnu/libc.so.6 -a malloc
perf record -e probe_libc:malloc --call-graph dwarf -p $pid_of_problematic_process
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Kurt Roeckx | 2020-11-10 19:44:46 | Re: BUG #16707: Memory leak |
Previous Message | PG Bug reporting form | 2020-11-10 18:47:49 | BUG #16708: Please add some more restrictions to the default systemd unit files |