Re: Properly handle OOM death?

From: Joe Conway <mail(at)joeconway(dot)com>
To: Israel Brewster <ijbrewster(at)alaska(dot)edu>
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:25:40
Message-ID: ccdc78ad-5cd4-6d27-5e90-1f46aad28c36@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/13/23 16:18, Israel Brewster wrote:
>> On Mar 13, 2023, at 11:42 AM, Joe Conway <mail(at)joeconway(dot)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(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.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Israel Brewster 2023-03-13 20:27:14 Re: Properly handle OOM death?
Previous Message Israel Brewster 2023-03-13 20:18:34 Re: Properly handle OOM death?