Re: BUG #18675: Postgres is not realasing memory causing OOM

I can now confirm that JIT is adding significant amount of memory on top of
what PG SQL is using. Memory reserved by PG still grows every day, but
doesn't grow as much as with JIT. So there is still something wrong with
Postgres.

db001..005 without JIT, db006..009 without JIT.
[image: obraz.png]

czw., 31 paź 2024 o 14:53 Daniel Gustafsson <daniel(at)yesql(dot)se> napisał(a):

> > On 31 Oct 2024, at 13:21, Maciej Jaros <eccenux(at)gmail(dot)com> wrote:
>
> > >> We terminate all queries running longer than 30 minutes....
> > > That just supports my speculation this is not the in-query memory leak
> where we allocate memory in a memory context, because that'd be freed at
> the end of a query. I'm not sure about what happens to memory allocated by
> LLVM if a query gets interrupted because of a timeout. How often do queries
> hit the 30-minute limit?
> >
> > Very rarely. Aside from bad deployments, long-running query kills happen
> maybe once a week or even once a month. It depends on the load (e.g. had
> more last month due to the beginning of the school year).
>
> The LLVMContextRef remains, currently for 100 queries as a heuristic since
> at
> time ot of the OOM fix commit there was no way of interrogating LLVM for
> how
> large the memory context was.
>
> IIRC this memory leak (which is capped in 16.4) only happens when
> performing
> inlining, raising the cost limit for inlining with jit_inline_above_cost
> and
> re-running problematic queries could give interesting insights.
>
> --
> Daniel Gustafsson
>
>