Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1
От | Stephan Knauss |
---|---|
Тема | Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1 |
Дата | |
Msg-id | 699cb370-17b8-3e72-02fe-1f96d494dfd7@stephans-server.de обсуждение исходный текст |
Ответ на | Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1
|
Список | 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 по дате отправления: