| 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 19:42:52 |
| Message-ID: | ec109215-9538-7e13-14a7-dc220d17c44d@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 3/13/23 15:18, Israel Brewster wrote:
> root(at)novarupta:~# cat /sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql(at)13-main(dot)service/memory.max
> max
> root(at)novarupta:~# cat /sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql(at)13-main(dot)service/memory.high
> max
> root(at)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter J. Holzer | 2023-03-13 20:16:29 | Re: Properly handle OOM death? |
| Previous Message | Jeffrey Walton | 2023-03-13 19:36:37 | Re: Properly handle OOM death? |