Re: Properly handle OOM death?
От | Joe Conway |
---|---|
Тема | Re: Properly handle OOM death? |
Дата | |
Msg-id | ec109215-9538-7e13-14a7-dc220d17c44d@joeconway.com обсуждение исходный текст |
Ответ на | Re: Properly handle OOM death? (Israel Brewster <ijbrewster@alaska.edu>) |
Ответы |
Re: Properly handle OOM death?
|
Список | pgsql-general |
On 3/13/23 15:18, Israel Brewster wrote: > root@novarupta:~# cat /sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql@13-main.service/memory.max > max > root@novarupta:~# cat /sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql@13-main.service/memory.high > max > root@novarupta:~# > > which would presumably indicate that it’s a system level limit being > exceeded, rather than a postgresql specific one? Yep > The syslog specifically says "Memory cgroup out of memory”, if that means > something (this is my first exposure to cgroups, if you couldn’t > tell). I am not entirely sure, but without actually testing it I suspect that since memory.max = high (that is, the limit is whatever the host has available) the OOM kill is technically a cgroup OOM kill even though it is effectively a host level memory pressure event. Did you try setting "vm.overcommit_memory=2"? -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-general по дате отправления: