From: | Israel Brewster <ijbrewster(at)alaska(dot)edu> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Properly handle OOM death? |
Date: | 2023-03-13 20:18:34 |
Message-ID: | 7B4AC414-F5C9-46E8-969E-B629414719FA@alaska.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Mar 13, 2023, at 11:42 AM, Joe Conway <mail(at)joeconway(dot)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 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.
That would make sense.
>
> Did you try setting "vm.overcommit_memory=2"?
Yeah:
root(at)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.
---
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2023-03-13 20:25:40 | Re: Properly handle OOM death? |
Previous Message | Peter J. Holzer | 2023-03-13 20:16:29 | Re: Properly handle OOM death? |