Re: Properly handle OOM death?
От | Joe Conway |
---|---|
Тема | Re: Properly handle OOM death? |
Дата | |
Msg-id | ccdc78ad-5cd4-6d27-5e90-1f46aad28c36@joeconway.com обсуждение исходный текст |
Ответ на | Re: Properly handle OOM death? (Israel Brewster <ijbrewster@alaska.edu>) |
Ответы |
Re: Properly handle OOM death?
Re: Properly handle OOM death? |
Список | pgsql-general |
On 3/13/23 16:18, Israel Brewster wrote: >> On Mar 13, 2023, at 11:42 AM, Joe Conway <mail@joeconway.com> wrote: >> 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. Sorry, actually meant "memory.max = max" here >> Did you try setting "vm.overcommit_memory=2"? > root@novarupta:~# sysctl -w vm.overcommit_memory=2 > sysctl: setting key "vm.overcommit_memory", ignoring: Read-only file system > I’m thinking I wound up with a container rather than a full VM after > all - and as such, the best solution may be to migrate to a full VM > with some swap space available to avoid the issue in the first place. > I’ll have to get in touch with the sys admin for that though. Hmm, well big +1 for having swap turned on, but I recommend setting "vm.overcommit_memory=2" even so. -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-general по дате отправления: