Le 12/08/2020 à 17:56, MichaelDBA a
écrit :
Just to see if work_mem is related to these memory problems, please lower it from 96MB to 16MB and do a reload:
pg_ctl -D <your pg data directory> reload
If you still see memory problems, the problem is elsewhere. Please report back. Thanks.
Don't forget to reset it back to 96MB if it's not the cause of the problem.
Regards,
Michael Vitale
JOIGNY Michael @Neteven wrote on 8/12/2020 10:54 AM:
Hi Michael, Tom,
Thanks for your help.
Le 12/08/2020 à 16:26, MichaelDBA a écrit :
Please specify some other stuff:Onprem
1. PG onprem or cloud? If cloud, which one and what instance type.
2. Is it a dedicated PG host? How many hyper threads and memory do you have?Yes dedicated PG host, 56 hyper threads and 380Go of memory.
3. Does PGBouncer run on another host or on the same host as PG?
I have a primary / stanby configuration using repmgr for replication.
PGbouncer is running on both of them.
@Tom, thanks i will have a look at this parameter.
"One thing that you might not have noticed is that "jit" defaults to on as of v12. Turning it off would prevent this specific crash case. (The fact that it's a crash comes from llvm's crummy error handling :-() You might still have OOM problems, but with luck they'd not take down the whole database."
Regards.
-- Cordialement. -------------------- NETEVEN Michael JOIGNY Service Exploitation - Ingénieur Systèmes 190 Avenue Jean Jaures - 75019 Paris mjoigny@xxxxxxxxxxx / adminsys@xxxxxxxxxxx www.neteven.com