From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Maciej Jaros <eccenux(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #18675: Postgres is not realasing memory causing OOM |
Date: | 2024-10-31 13:53:21 |
Message-ID: | 5232B290-5C90-4819-A0F6-A07DE14A20C4@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bastien Roucariès | 2024-10-31 15:41:24 | Detection of hadware feature => please do not use signal |
Previous Message | PG Bug reporting form | 2024-10-31 13:15:20 | BUG #18681: [ECPG] heap-read-out-of-bounds |