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
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
