Re: Properly handle OOM death?
От | Israel Brewster |
---|---|
Тема | Re: Properly handle OOM death? |
Дата | |
Msg-id | 7B4AC414-F5C9-46E8-969E-B629414719FA@alaska.edu обсуждение исходный текст |
Ответ на | Re: Properly handle OOM death? (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Properly handle OOM death?
|
Список | pgsql-general |
> On Mar 13, 2023, at 11:42 AM, Joe Conway <mail@joeconway.com> wrote: > > On 3/13/23 15:18, Israel Brewster wrote: >> 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 whateverthe host has available) the OOM kill is technically a cgroup OOM kill even though it is effectively a host levelmemory pressure event. That would make sense. > > Did you try setting "vm.overcommit_memory=2"? Yeah: 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 migrateto a full VM with some swap space available to avoid the issue in the first place. I’ll have to get in touch withthe sys admin for that though. --- Israel Brewster Software Engineer Alaska Volcano Observatory Geophysical Institute - UAF 2156 Koyukuk Drive Fairbanks AK 99775-7320 Work: 907-474-5172 cell: 907-328-9145 > > -- > Joe Conway > PostgreSQL Contributors Team > RDS Open Source Databases > Amazon Web Services: https://aws.amazon.com >
В списке pgsql-general по дате отправления: