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

Sorry:
db001..005 without JIT, db006..009 with JIT.

pt., 8 lis 2024 o 11:29 Maciej Jaros <eccenux(at)gmail(dot)com> napisał(a):

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