public inbox for [email protected]
help / color / mirror / Atom feedFrom: Joe Conway <[email protected]>
To: Priya V <[email protected]>
To: [email protected]
Subject: Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet
Date: Tue, 5 Aug 2025 14:52:25 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAFsZ43xFxjSiONwRccXBQXZrPRd+Lh7XAkSVEG1ai165xPcoDA@mail.gmail.com>
References: <CAFsZ43xFxjSiONwRccXBQXZrPRd+Lh7XAkSVEG1ai165xPcoDA@mail.gmail.com>
On 8/5/25 13:01, Priya V wrote:
> *Environment:*
> *PostgreSQL Versions:* Mix of 13.13 and 15.12 (upgrades in progress
> to be at 15.12 currently both are actively in use)
PostgreSQL 13 end of life after November 13, 2025
> *OS / Kernel:* RHEL 7 & RHEL 8 variants, kernels in the 4.14–4.18 range
RHEL 7 has been EOL for quite a while now. Note that you have to watch
out for collation issues/corrupted indexes after OS upgrades due to
collations changing with newer glibc versions.
> *Swap:* Currently none
bad idea
> *Workload:* Highly mixed — OLTP-style internal apps with
> unpredictable query patterns and connection counts
>
> *Goal:* Uniform, safe memory settings across the fleet to avoid
> kernel or database instability
> We’re considering:
> *|vm.overcommit_memory = 2|* for strict accounting
yes
> Increasing |vm.overcommit_ratio| from 50 → 80 or 90 to better
> reflect actual PostgreSQL usage (e.g., |work_mem| reservations that
> aren’t fully used)
work_mem does not reserve memory -- it is a maximum that might be used
in memory for a particular operation
> *Our questions for those running large PostgreSQL fleets:*
> 1.
> What |overcommit_ratio| do you find safe for PostgreSQL without
> causing kernel memory crunches?
Read this:
https://www.cybertec-postgresql.com/en/what-you-should-know-about-linux-memory-overcommit-in-postgre...
> 2.
> Do you prefer |overcommit_memory = 1| or |= 2| for production stability?
Use overcommit_memory = 2 for production stability
> 3.
> How much swap (if any) do you keep in large-memory servers where
> PostgreSQL is the primary workload? Is having swap configured a good
> idea or not ?
You don't necessary need a large amount of swap, but you definitely
should not disable it.
Some background on that:
https://chrisdown.name/2018/01/02/in-defence-of-swap.html
> 4.
> Any real-world cases where kernel accounting was too strict or too
> loose for PostgreSQL?
In my experience the biggest issues are when postgres is running in a
memory constrained cgroup. If you want to constrain memory with cgroups,
use cgroup v2 (not 1) and use memory.high to constrain it, not memory.max.
> 5. What settings to go with if we are not planning on using swap ?
IMHO do not disable swap on Linux, at least not on production, ever.
> We’d like to avoid both extremes:
> Too low a ratio → PostgreSQL backends failing allocations even with
> free RAM
Have you actually seen this or are you theorizing?
> Too high a ratio → OOM killer terminating PostgreSQL under load spikes
If overcommit_memory = 2, overcommit_ratio is reasonable (less than 100,
maybe 80 or so as you suggested), and swap is not disabled, and you are
not running in a memory constrained cgroup, I would be very surprised if
you will ever get hit by the OOM killer. And if you do, things are so
bad the database was probably dying anyway.
HTH,
--
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox