MIME-Version: 1.0
From: Priya V <mailme0216@gmail.com>
Date: Tue, 5 Aug 2025 12:01:19 -0500
Message-ID: 
 <CAFsZ43xFxjSiONwRccXBQXZrPRd+Lh7XAkSVEG1ai165xPcoDA@mail.gmail.com>
Subject: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet
To: pgsql-performance@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000096c1b063ba12d15"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFsZ43xFxjSiONwRccXBQXZrPRd%2BLh7XAkSVEG1ai165xPcoDA%40mail.gmail.com>
Precedence: bulk

--000000000000096c1b063ba12d15
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Postgres community,

We operate a large PostgreSQL fleet (~15,000 databases) on dedicated Linux
hosts.
Each host runs *multiple PostgreSQL instances* (multi-instance setup, not
just multiple DBs inside one instance).

*Environment:*

   -

   *PostgreSQL Versions:* Mix of 13.13 and 15.12 (upgrades in progress to
   be at 15.12 currently both are actively in use)
   -

   *OS / Kernel:* RHEL 7 & RHEL 8 variants, kernels in the 4.14=E2=80=934.1=
8 range
   -

   *RAM:* 256 GiB (varies slightly)
   -

   *Swap:* Currently none
   -

   *Workload:* Highly mixed =E2=80=94 OLTP-style internal apps with unpredi=
ctable
   query patterns and connection counts
   -

   *Goal:* Uniform, safe memory settings across the fleet to avoid kernel
   or database instability

We=E2=80=99re reviewing vm.overcommit_* settings because we=E2=80=99ve seen=
 conflicting
guidance:

   -

   vm.overcommit_memory =3D 2 gives predictability but can reject allocatio=
ns
   early
   -

   vm.overcommit_memory =3D 1 is more flexible but risks OOM kills if many
   backends hit peak memory usage at once

We=E2=80=99re considering:

   -

   *vm.overcommit_memory =3D 2* for strict accounting
   -

   Increasing vm.overcommit_ratio from 50 =E2=86=92 80 or 90 to better refl=
ect
   actual PostgreSQL usage (e.g., work_mem reservations that aren=E2=80=99t=
 fully
   used)

*Our questions for those running large PostgreSQL fleets:*

   1.

   What overcommit_ratio do you find safe for PostgreSQL without causing
   kernel memory crunches?
   2.

   Do you prefer overcommit_memory =3D 1 or =3D 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 ide=
a
   or not ?
   4.

   Any real-world cases where kernel accounting was too strict or too loose
   for PostgreSQL?
   5. What settings to go with if we are not planning on using swap ?

We=E2=80=99d like to avoid both extremes:

   -

   Too low a ratio =E2=86=92 PostgreSQL backends failing allocations even w=
ith free
   RAM
   -

   Too high a ratio =E2=86=92 OOM killer terminating PostgreSQL under load =
spikes

Any operational experiences, tuning recommendations, or kernel/PG
interaction pitfalls would be very helpful.

TIA

--000000000000096c1b063ba12d15
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Postgres community,</div><div><p>We operate a l=
arge PostgreSQL fleet (~15,000 databases) on dedicated Linux hosts.<br>
Each host runs <strong>multiple PostgreSQL instances</strong> (multi-instan=
ce setup, not just multiple DBs inside one instance).</p>
<p><strong>Environment:</strong></p>
<ul><li>
<p><strong>PostgreSQL Versions:</strong> Mix of 13.13 and 15.12 (upgrades i=
n progress to be at 15.12 currently both are actively in use)</p>
</li><li>
<p><strong>OS / Kernel:</strong> RHEL 7 &amp; RHEL 8 variants, kernels in t=
he 4.14=E2=80=934.18 range</p>
</li><li>
<p><strong>RAM:</strong> 256 GiB (varies slightly)</p>
</li><li>
<p><strong>Swap:</strong> Currently none</p>
</li><li>
<p><strong>Workload:</strong> Highly mixed =E2=80=94 OLTP-style internal ap=
ps with unpredictable query patterns and connection counts</p>
</li><li>
<p><strong>Goal:</strong> Uniform, safe memory settings across the fleet to=
 avoid kernel or database instability</p></li></ul><div><p>We=E2=80=99re re=
viewing <code>vm.overcommit_*</code> settings because we=E2=80=99ve seen co=
nflicting guidance:</p>
<ul><li>
<p><code>vm.overcommit_memory =3D 2</code> gives predictability but can rej=
ect allocations early</p>
</li><li>
<p><code>vm.overcommit_memory =3D 1</code> is more flexible but risks OOM k=
ills if many backends hit peak memory usage at once</p>
</li></ul>
<p>We=E2=80=99re considering:</p>
<ul><li>
<p><strong><code>vm.overcommit_memory =3D 2</code></strong> for strict acco=
unting</p>
</li><li>
<p>Increasing <code>vm.overcommit_ratio</code> from 50 =E2=86=92 80 or 90 t=
o better reflect actual PostgreSQL usage (e.g., <code>work_mem</code> reser=
vations that aren=E2=80=99t fully used)</p>
</li></ul>
<p><strong>Our questions for those running large PostgreSQL fleets:</strong=
></p>
<ol><li>
<p>What <code>overcommit_ratio</code> do you find safe for PostgreSQL witho=
ut causing kernel memory crunches?</p>
</li><li>
<p>Do you prefer <code>overcommit_memory =3D 1</code> or <code>=3D 2</code>=
 for production stability?</p>
</li><li>
<p>How much swap (if any) do you keep in large-memory servers where Postgre=
SQL is the primary workload? Is having swap configured a good idea or not ?=
=C2=A0</p>
</li><li>
<p>Any real-world cases where kernel accounting was too strict or too loose=
 for PostgreSQL?</p></li><li>What settings to go with if we are not plannin=
g on using swap ?</li></ol>
<p>We=E2=80=99d like to avoid both extremes:</p>
<ul><li>
<p>Too low a ratio =E2=86=92 PostgreSQL backends failing allocations even w=
ith free RAM</p>
</li><li>
<p>Too high a ratio =E2=86=92 OOM killer terminating PostgreSQL under load =
spikes</p>
</li></ul>
<p>Any operational experiences, tuning recommendations, or kernel/PG intera=
ction pitfalls would be very helpful.</p>
<p>TIA</p><br></div><br></div><div><br></div></div>

--000000000000096c1b063ba12d15--