Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1 - Mailing list pgsql-general

From Stephan Knauss
Subject Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1
Date
Msg-id 699cb370-17b8-3e72-02fe-1f96d494dfd7@stephans-server.de
Whole thread Raw
In response to Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hello Tom,

On 31.03.2021 20:24, Tom Lane wrote:
> Based on nearby threads, it occurs to me to ask whether you have JIT
> enabled, and if so whether turning it off helps.  There seems to be
> a known leak of the code fragments generated by that in some cases.

That's it!

I am quite surprised that a functionality, which is on by default does 
generate such a massive leak and goes sort of undetected.

A single backend was leaking 250MB/hour, with my multiple connections it 
was 2GB. But exactly that happened.

Doing a set jit=off immediately stopped the leak.


You mentioned that this seems to be known. Do you have pointers to the 
relevant bug-tracker/thread? I would like to follow up on this.

I have not measured the impact of jit, but in theory it could bring 
larger performance benefits. So having it enabled sounds like a good 
idea, once it stops leaking.


I tried running Valgrind on postgres but I had not much success with it. 
processes seemed to terminate quite frequently. My last use of Valgrind 
is a while ago and my use-case back then was probably much simpler.

Is it known which queries are leading to a leak? I still have the 
recording of mine, including explain. Would it help to narrow it further 
down to single queries which leak? Or is the JIT re-creating optimized 
code for each slightly modified one without freeing the old ones? So 
re-running the same query would not leak?

https://downloads.osm-tools.org/postgresql-2021-04-03_183913.csv.gz


Stephan





pgsql-general by date:

Previous
From: "A. Reichstadt"
Date:
Subject: Re: How to deny access to Postgres when connected from host/non-local
Next
From: Bruce Momjian
Date:
Subject: Re: Is replacing transactions with CTE a good idea?