Re: BUG #16707: Memory leak
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Date: 2020-11-10T19:35:17Z
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
Commits
-
llvmjit: Use explicit LLVMContextRef for inlining
- 3b991f81c457 12.18 landed
- 10912f7d4ff0 13.14 landed
- 75a20a4b4b44 14.11 landed
- aef521849b68 15.6 landed
- 2cf50585e54a 16.2 landed
- 9dce22033d5d 17.0 landed