Hi, Thanks for the good point: $ sysctl vm.overcommit_memory vm.overcommit_memory = 0
That is a difference, the old pg11 running on Ubuntu 18.4 had disabled overcommit (vm.overcommit_memory = 2). Anyway, on a dedicated DB server box with 123GB RAM running only vacuum (14 parallel processes (2GB maintenance workmen)) and shared buffers 22GB seems to me unlikely to hit available memory. During Sunday (low load) and Monday so far, it has not reoccurred. Kind regards Ales Zeleny ne 22. 6. 2025 v 0:44 odesílatel Tomas Vondra <to...@vondra.me> napsal: > On 6/21/25 23:09, Aleš Zelený wrote: > > Hello, > > ... > > > > The application benefits from parallel queries, so despite the first > > temptation to disable parallel queries (based on log entries correlation > > only, but is that the root cause?) I did not want to disable parallel > > queries, if there is another workaround/solution/fix available. > > > > Thanks for any hints on how to provide more information if needed, as > > well as for fix/workaround advice. > > > > Could it be that you simply ran out of memory, or perhaps hit the > overcommit? What does sysctl say? > > sysctl vm.overcommit_memory > > And what's CommitLimit/Committed_AS in /proc/meminfo? IIRC the shmem is > counted against the limit, and if the system does not have significant > swap, it's not uncommon to hit that (esp. with overcommit_memory=2). > > > regards > > -- > Tomas Vondra > >
