| From: | Joao Detomini <joao(dot)detomini(at)enterprisedb(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | doc: Document Linux cgroup memory limits |
| Date: | 2026-10-01 22:19:38 |
| Message-ID: | CABH8dKwkp1_TzR7nxfvSpRSLD1b33xw7N_VLMLy3MiaEjAEPNw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
The "Linux Memory Overcommit" section of the docs only talks about
host-wide behavior (vm.overcommit_memory, oom_score_adj), but a lot of
installations now run Postgres in containers, where a cgroup memory
limit is what actually triggers the OOM killer, regardless of the
host's overcommit settings.
The attached patch adds a short subsection covering this: how
memory.max behaves with cgroup v2, what happens when a backend is
killed, what counts towards the limit (including the huge pages
caveat), and a pointer to the kernel documentation.
The patch is against master, and the docs build cleanly here. This is
my first contribution, so I'd appreciate any feedback on the wording or
on things I should add or drop.
Thanks,
João Marcelo
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-doc-Document-Linux-cgroup-memory-limits.patch | application/octet-stream | 3.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-10-01 22:39:21 | Re: Partial indexes on system catalogs |
| Previous Message | Ayush Tiwari | 2026-10-01 22:16:36 | Re: [Patch] Batch fsyncs when recycling WAL segments |