Measure PG18 connection memory overhead on Ubuntu

[NikolayS]

Summary

I repeated Andres Freund's 2020 connection-memory measurement method on PostgreSQL 18.3 on Ubuntu 24.04, with both huge_pages = off and huge_pages = on.

Reference method: https://blog.anarazel.de/2020/10/07/measuring-the-memory-overhead-of-a-postgres-connection/

Short version: ps/top RSS is still the wrong metric. Using Pss_Anon from /proc/$pid/smaps_rollup plus VmPTE from /proc/$pid/status, a PG18 backend running a simple pgbench read-only workload on this host was:

huge_pages	shared_buffers	median overhead	range
off	1GB	2.64 MiB	2.17–2.92 MiB
on	1GB	1.51 MiB	1.51–1.52 MiB

For reference, an earlier huge_pages = off run with shared_buffers = 2GB measured 2.33 MiB median across 10 sampled pgbench backends. The final comparison table above uses 1GB for both modes because this host could allocate only 594 huge pages (~1.16 GiB) without reboot/compaction.

Environment

Host: Linux openclaw-server 6.8.0-94-generic #96-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 9 20:36:55 UTC 2026 x86_64
OS: Ubuntu 24.04.3 LTS
PostgreSQL: PostgreSQL 18.3 (Ubuntu 18.3-1.pgdg24.04+1)
THP: always [madvise] never
Huge page size: 2048 kB

Cluster settings for the comparable runs:

max_connections = 1100
shared_buffers = 1GB
work_mem = 4MB
jit = on

For the huge_pages = on run, host huge pages were temporarily raised from 0 to 594 and then restored to 0 after the experiment.

Workload

Throwaway PG18 cluster under /tmp, Unix socket only.

pgbench -i -s 100 bench
pgbench -S -M prepared -c 1024 -j 16 -T 90 bench

At sampling time in both runs:

connected pgbench backends: 1024
pg_stat_activity rows: 1033

Measurement method

Same approximation as the blog post:

per-connection overhead ~= Pss_Anon + VmPTE

Where:

• Pss_Anon comes from /proc/$pid/smaps_rollup
• VmPTE comes from /proc/$pid/status
• RssFile is ignored because it is mostly executable/shared library mappings
• RssShmem / Pss_Shmem is not counted as private connection memory

Results: huge_pages = off

Cluster:

huge_pages = off
shared_buffers = 131072 8kB  # 1GB
nr_hugepages = 0

Fresh sleeping connection before pgbench:

RssAnon:        3344 kB
RssFile:        8576 kB
RssShmem:       8448 kB
VmPTE:           236 kB
HugetlbPages:      0 kB
Pss:            8296 kB
Pss_Anon:       1510 kB
Pss_File:       3055 kB
Pss_Shmem:      3731 kB

Sampled pgbench backends:

pid	RssAnon kB	RssFile kB	RssShmem kB	HugetlbPages kB	Pss_Anon kB	VmPTE kB	approx overhead MiB
177527	3216	9088	29184	0	1398	820	2.17
177528	3216	9088	31360	0	1398	868	2.21
177529	3344	8960	34560	0	1398	1064	2.40
177531	3216	9088	39424	0	1398	1132	2.47
177532	3344	9088	42112	0	1410	1236	2.58
177533	3344	9088	46464	0	1398	1360	2.69
177534	3472	9088	48128	0	1410	1372	2.72
177537	3472	9088	53504	0	1398	1504	2.83
177538	3344	8960	57984	0	1398	1580	2.91
177539	3344	9088	58240	0	1398	1596	2.92

Summary:

min:    2218 kB = 2.17 MiB
median: 2702 kB = 2.64 MiB
avg:    2653.6 kB = 2.59 MiB
max:    2994 kB = 2.92 MiB

pgbench:

number of transactions actually processed: 3176975
number of failed transactions: 0 (0.000%)
latency average = 28.249 ms
tps = 36249.676823 (without initial connection time)

Results: huge_pages = on

Cluster:

huge_pages = on
shared_buffers = 131072 8kB  # 1GB
nr_hugepages = 594
HugePages_Total = 594
HugePages_Free at sampling = 108

Fresh sleeping connection before pgbench:

RssAnon:        3424 kB
RssFile:        8320 kB
RssShmem:          0 kB
VmPTE:           144 kB
HugetlbPages:  55296 kB
Pss:            4598 kB
Pss_Anon:       1508 kB
Pss_File:       2991 kB
Pss_Shmem:        99 kB

Sampled pgbench backends:

pid	RssAnon kB	RssFile kB	RssShmem kB	HugetlbPages kB	Pss_Anon kB	VmPTE kB	approx overhead MiB
157621	3296	8960	0	516096	1398	144	1.51
157622	3424	9088	128	438272	1398	144	1.51
157626	3280	9088	0	561152	1398	144	1.51
157627	3424	9088	128	546816	1398	144	1.51
157628	3424	9088	128	743424	1410	144	1.52
157629	3424	9088	128	741376	1398	144	1.51
157634	3296	9088	0	722944	1398	144	1.51
157637	3424	9088	128	958464	1410	144	1.52
157641	3412	9088	128	776192	1410	144	1.52
157642	3424	9088	128	786432	1398	144	1.51

Summary:

min:    1542 kB = 1.51 MiB
median: 1542 kB = 1.51 MiB
avg:    1545.6 kB = 1.51 MiB
max:    1554 kB = 1.52 MiB

pgbench:

number of transactions actually processed: 4344743
number of failed transactions: 0 (0.000%)
latency average = 20.729 ms
tps = 49399.941112 (without initial connection time)

Notes

• Huge pages reduced VmPTE from hundreds/thousands of kB down to a stable 144 kB in this run. That's the main difference, same as Andres described in 2020.
• HugetlbPages looks huge per backend and should not be interpreted as private per-connection memory. The approximation intentionally uses Pss_Anon + VmPTE.
• RSS remains misleading: with huge_pages = off, RssShmem grows as the backend touches shared buffers; with huge_pages = on, the same shared buffer footprint moves to HugetlbPages and page-table overhead collapses.
• On this host, PG18 connection overhead in this workload is roughly 2.6 MiB with huge pages off and 1.5 MiB with huge pages on.

Reproducer

PG=/usr/lib/postgresql/18/bin
BASE=/tmp/pg18-conn-overhead
DATA=$BASE/data
SOCK=$BASE/socket
PORT=55418

rm -rf "$BASE"
mkdir -p "$SOCK"
"$PG/initdb" -D "$DATA" --no-locale --encoding=UTF8
cat >> "$DATA/postgresql.conf" <<EOF
port = $PORT
listen_addresses = ''
unix_socket_directories = '$SOCK'
max_connections = 1100
shared_buffers = '1GB'
huge_pages = on   # or off
fsync = off
synchronous_commit = off
full_page_writes = off
EOF
cat > "$DATA/pg_hba.conf" <<EOF
local all all trust
EOF
"$PG/pg_ctl" -D "$DATA" -l "$BASE/postgres.log" -w start
export PGHOST=$SOCK PGPORT=$PORT PGDATABASE=postgres PGUSER="$USER"
"$PG/createdb" bench
export PGDATABASE=bench
"$PG/pgbench" -i -s 100 bench
"$PG/pgbench" -S -M prepared -c 1024 -j 16 -T 90 bench

# During the pgbench run, pick backend PIDs from pg_stat_activity and inspect:
grep -E '^(Rss|HugetlbPages|VmPTE)' /proc/$pid/status
grep -E '^(Pss|Pss_Anon|Pss_File|Pss_Shmem):' /proc/$pid/smaps_rollup

[NikolayS]

Follow-up testing plan

Picking up from the existing measurements (huge_pages off → 2.64 MiB, on → 1.51 MiB at sb=1GB, c=1024). Goal: sharpen or falsify those numbers on this same host.

A small sanity finding first: in the v1 results file (/tmp/pg18-conn-overhead/results.md), the "approx overhead" lines show a different VmPTE than the per-pid status block immediately above them. That's because the v1 script printed read_status (snapshot 1) then re-read /proc/$pid/status later (snapshot 2) for the arithmetic, so VmPTE drifted upward between the two reads. The v2 script (-off-1gb, -on) fixed this by computing from one snapshot. The conclusion is unchanged but worth flagging — and is one of the explicit checks Sam Jr. asked me to do. The new v3 harness reads /proc/$pid/status and /proc/$pid/smaps_rollup once each and parses both from in-memory copies.

Plan, all under /tmp/pg18-conn-agent/<run-name>/ (existing /tmp/pg18-conn-overhead* outputs preserved):

1. Repeatability — repeat huge_pages=off / sb=1GB / c=1024 three times, 50 samples each, to get across-run variance.
2. Client count sweep — c = 10, 100, 500, 1024 at huge_pages=off / sb=1GB.
3. Idle vs active — N idle connections (psql holding pg_sleep), N "warm-then-idle" (SELECT count(*) once then sleep), N pgbench backends — does idle drop the page-table cost?
4. shared_buffers sweep (huge_pages=off, c=100) — sb = 128MB / 1GB / 4GB to verify the VmPTE term scales with touched-shmem.
5. jit=off sanity check at c=100, huge_pages=off, sb=1GB.
6. huge_pages=try with nr_hugepages=594 (should match on) and with nr_hugepages=0 (should match off).
7. Drift-over-time — sample 100 backends in three waves (≈15s, ≈45s, ≈75s) to see whether the median moves and how representative a 10-sample reading is.

Harness: /tmp/pg18-conn-agent/v3.sh. Raw CSV per run: /tmp/pg18-conn-agent/<run>/samples.csv. Comments will follow with results.

Constraints: only throwaway clusters under /tmp; nr_hugepages is restored to whatever it was at start (currently 0); no production clusters touched.

[NikolayS]

Finding 1: sampling method matters; the 2.64 MiB median was biased low

Re-ran the same baseline (huge_pages=off, sb=1GB, c=1024 -j16, 60s pgbench) three times, but sampled 50 backends per run picked by ORDER BY random() rather than the first 10 by pid.

run	n_samples	median overhead	mean	p10	p90	sd
repeat-1	40	3.42 MiB	3.15	2.22	3.59	0.61
repeat-2	38	3.45 MiB	3.13	1.84	3.59	0.64
repeat-3	41	3.43 MiB	3.18	2.34	3.58	0.57

The original "first 10 backends by pid" method picked the earliest-spawned pgbench backends, which had touched the fewest shared buffers and therefore had the smallest VmPTE. With random sampling across all 1024 backends, the median lands ~30% higher.

Per-run breakdown of the overhead = Pss_Anon + VmPTE components (huge_pages=off):

                Pss_Anon (kB)        VmPTE (kB)
              med   mean   sd      med   mean   sd
repeat-1     1382  1378   32     2130  1850  606
repeat-2     1382  1384   53     2148  1818  639
repeat-3     1386  1387    8     2128  1871  579

So Pss_Anon is rock-solid at ~1.36 MiB across runs, but VmPTE is the noisy term — it ranges 240 → 2300 kB within a single run depending on how much of shared_buffers each individual backend has touched. That's the source of all the across-run variation.

Across-run variance for the median is small (3.42 / 3.45 / 3.43 MiB → cv ≈ 0.4%); within-run sd is ~600 kB.

Raw CSVs: /tmp/pg18-conn-agent/repeat-{1,2,3}/samples.csv. Harness: /tmp/pg18-conn-agent/v3.sh.

Updated huge_pages=off estimate (sb=1GB, c=1024 active pgbench, 50 random samples):

• median ≈ 3.4 MiB, p10–p90 ≈ 2.2–3.6 MiB.

[NikolayS]

Finding 2: client-count sweep (huge_pages=off, sb=1GB, 60s pgbench)

Same workload, varying -c:

clients	n_samples	tps total	tps/backend	median overhead	mean	p10	p90	sd
10	10	34,674	3,467	2.60 MiB	2.53	2.02	3.07	0.41
100	50	60,547	605	3.60 MiB	3.55	3.57	3.60	0.18
500	40	41,663	83	3.57 MiB	3.39	2.95	3.60	0.42
1024	37	30,432	30	3.46 MiB	3.15	2.15	3.57	0.58

Pss_Anon median is essentially constant across c (1.35–1.45 MiB). All movement is in VmPTE:

clients	VmPTE median (kB)	VmPTE p90 (kB)
10	1174	1656
100	2288	2288
500	2278	2296
1024	2164	2276

VmPTE plateaus near 2288 kB (≈ 8 bytes × 256 K pages × 1.0 — i.e. the page-table for the full 1GB shared_buffers being privately mapped per backend). c=10 stays well below the plateau even at 3,467 tps/backend, because with only 10 backends sharing 1GB of shared_buffers each backend's footprint is bounded by what 60s of randomised single-row lookups against pgbench_accounts (~1.3GB at scale 100) actually touch and keep mapped.

The implication: at any reasonable per-backend load, on this host the per-backend overhead saturates at roughly 3.5–3.6 MiB without huge pages once each backend has touched most of shared_buffers. The 1GB sb / 1024 client number is an under-estimate by ~30% relative to what a fleet of busy backends would actually cost.

CSVs: /tmp/pg18-conn-agent/cli-{10,100,500,1024}/samples.csv.

[NikolayS]

Finding 3: idle vs active vs "warm-then-idle" — the workload itself dominates

200 connections, huge_pages=off, sb=1GB, scale 100. Three modes:

• idle: 200 psql sessions running SELECT pg_sleep(60) only. They never touch any table data.
• active: 200 pgbench -S -M prepared backends.
• warm: 200 psql sessions running SELECT count(*) FROM pgbench_accounts; SELECT pg_sleep(60); — they read every row of the 1.3GB table, then sit idle while we sample.

Sample of 50 random backends per mode (60s after start):

mode	median overhead	Pss_Anon med	VmPTE med	RssAnon med	Private_Dirty med
idle	1.46 MiB	1258 kB	240 kB	3304 kB	1248 kB
active	3.59 MiB	1390 kB	2288 kB	3416 kB	1388 kB
warm	10.07 MiB	9437 kB	880 kB	11292 kB	9456 kB

Interpretation:

• idle is the floor. VmPTE collapses to 240 kB (just the page table for shared_buffers metadata that all backends touch on attach). Pss_Anon ~1.25 MiB. So a fully idle PG18 backend on this host costs ~1.5 MiB independent of huge_pages.
• active pgbench holds the ratio Sam Jr. described: anon stays small, VmPTE grows because each backend has touched a wide, mostly-disjoint subset of the 1GB shared_buffers.
• warm-then-idle is a surprise: a single full table scan leaves ~9 MiB of Pss_Anon resident after the query has finished. This is large enough to dwarf the page-table effect. JIT is the most likely culprit (count(*) on 10M rows triggers expression JIT and llvmjit-emitted code/data sticks around). I verify this in the next test.

So the "X MiB per connection" answer is wildly workload-dependent — anywhere from 1.5 to 10+ MiB on this host, before huge_pages even enters the picture.

Raw: /tmp/pg18-conn-agent/mode-{idle,warm,active-200}/samples.csv.

[NikolayS]

Finding 4: confirmed — that 9 MiB of "warm" anon memory is JIT

Re-ran the warm test (200 connections, each does SELECT count(*) FROM pgbench_accounts; pg_sleep(60)) with jit = off:

mode	jit	median overhead	Pss_Anon med	VmPTE med
warm	on	10.07 MiB	9437 kB	880 kB
warm	off	2.16 MiB	1518 kB	688 kB
active (c=100)	on	3.60 MiB	1399 kB	2288 kB
active (c=100)	off	3.61 MiB	1407 kB	2288 kB

So the warm-mode anomaly was JIT: a single ~1.3GB sequential scan triggered llvmjit and left ~8 MiB of private anon memory pinned per backend, even after the query completed. With jit=off the warm overhead drops to a value consistent with the active estimate.

For pgbench -S -M prepared, the per-query cost is well below jit_above_cost, so JIT never kicks in and jit=on vs jit=off are indistinguishable. Sam Jr.'s prior runs with jit=on are therefore not contaminated by JIT.

Practical implication: any backend that has run an analytical query on this PG18 build should be assumed to carry an extra ~8 MiB until it disconnects. With 1024 backends that's ~8 GiB on top of the page-table / shared-buffer-PTE cost.

CSVs: /tmp/pg18-conn-agent/mode-warm-jitoff/samples.csv, /tmp/pg18-conn-agent/cli-100-jitoff/samples.csv.

[NikolayS]

Finding 5: shared_buffers sweep (huge_pages=off, c=100, 60s pgbench)

shared_buffers	median overhead	mean	sd	VmPTE med	Pss_Shmem med	Pss_Anon med
128MB	1.83 MiB	1.83	0.00	468 kB	1376 kB	1403 kB
1GB	3.60 MiB	3.57	0.15	2280 kB	10720 kB	1407 kB
4GB	4.61 MiB	4.43	0.44	3326 kB	15584 kB	1395 kB

VmPTE tracks shared_buffers but is bounded by what each backend actually touches:

• 128MB sb: every backend touches the whole pool quickly → VmPTE saturates at ~468 kB and the 50-sample sd is 0 (all backends converge to the same pages).
• 1GB sb: most pages touched after 60s → VmPTE ≈ 2.2 MB ≈ 8 bytes × 256K pages.
• 4GB sb: pgbench_accounts (~1.3GB at scale 100) only covers a third of the pool, so VmPTE plateaus around 3.3 MB rather than the theoretical 8 MB ceiling.

Pss_Anon is essentially constant (~1.4 MiB) — independent of shared_buffers. So the formula overhead ≈ Pss_Anon + VmPTE decomposes cleanly: anon is per-backend boilerplate, VmPTE scales with how much of shared_buffers the backend has touched.

So if a customer wants to change shared_buffers, the per-connection memory cost on this host (no huge pages) goes roughly:

overhead(MiB) ≈ 1.4 + 8e-3 × (touched_shared_buffer_MiB)

Raw: /tmp/pg18-conn-agent/sb-{128MB,1GB,4GB}/samples.csv.

[NikolayS]

Finding 6: huge_pages=try and re-validated huge_pages=on

huge_pages	nr_hugepages at start	sb	c	n	median overhead	Pss_Anon med	VmPTE med
try	0	1GB	1024	42	3.50 MiB	1390 kB	2192 kB
try	594	1GB	1024	50	1.50 MiB	1390 kB	144 kB
on	594	1GB	1024	50	1.49 MiB	1386 kB	136 kB

huge_pages=try does exactly what the docs say: indistinguishable from on when enough hugepages are reserved, indistinguishable from off when there aren't.

The huge_pages=on rerun with 50 random samples lands at 1.49 MiB, essentially identical to the original 1.51 MiB from the first 10 by pid. Sampling method only matters when huge_pages=off — with huge pages on, every backend has the same ~136 kB VmPTE because the page-table for the 1GB shared_buffers needs only one PMD entry per 2MB, so per-backend variation collapses.

HugetlbPages per backend ranges from 51 MB to 1.1 GB — that's the same 1GB shmem segment, with each backend's "view" of how much it has touched. It is not private memory; it should not be charged per connection.

State proof — nr_hugepages restored to 0 after the experiment:

HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB

(Started this session at nr_hugepages = 0, ended at nr_hugepages = 0.)

CSVs: /tmp/pg18-conn-agent/hp-{try-0,try-594,on-1024}/samples.csv.

[NikolayS]

Finding 7: drift over time + table-scale sensitivity

Drift across sampling waves (huge_pages=off, sb=1GB, c=200, 120s pgbench, 50 samples per wave at 0/20/40s):

wave	n captured	min	p10	median	mean	p90	max	sd
wave1 (~start)	50	2182	3622	3690	3613	3694	3694	271
wave2 (~20s in)	40	3674	3678	3690	3688	3694	3694	7

The median doesn't move; the variance collapses. Wave 1 catches some backends still ramping up their VmPTE, so sd is ~270 kB. By wave 2 every backend has touched most of shared_buffers and they all converge to the ~3690 kB plateau (sd 7 kB). Wave 3 dropped out of the sample because the script's per-wave psql + 50× /proc snapshots took longer than expected; that's a known harness limit, not a measurement issue. The c=1024 variant of this test landed at the same plateau (med 3686, then 3697 by wave 2).

So the steady-state per-backend cost on this host with huge_pages=off, sb=1GB and a busy pgbench load is 3.6 MiB, with a ~10–30 second ramp from spawn.

Scale (shared_buffers vs working-set) sweep, c=200, 60s pgbench:

scale	table size	sb	median overhead	VmPTE med
10	~130 MB	1GB	1.88 MiB	548 kB
100	~1.3 GB	1GB	3.60 MiB	2280 kB
200	~2.6 GB	1GB	3.58 MiB	2284 kB

VmPTE = 8 bytes × (pages of shared_buffers actually touched). At scale=10 the table fits entirely in shared_buffers, so only ~130 MB worth of pages are ever mapped per backend → VmPTE caps low. At scale ≥ 100 the table exceeds shared_buffers, so backends keep cycling pages and the VmPTE plateaus at ~2.2 MB (= 256 K pages × 8 bytes). The per-connection memory cost therefore depends on how much of shared_buffers is actually being reused, not on shared_buffers itself.

CSVs: /tmp/pg18-conn-agent/{drift2,drift3,scale-10,scale-200,late}/samples.csv.

[NikolayS]

Finding 8: workload type (writes / simple / prepared) — same ballpark

Same host (huge_pages=off, sb=1GB, c=100, 60s, 50 random samples):

pgbench mode	flags	tps	median overhead	Pss_Anon med	VmPTE med	Private_Dirty med
select-only prepared	-S -M prepared	60,547	3.60 MiB	1399	2288	1388
select-only simple	-S -M simple	48,344	3.58 MiB	1375	2292	1364
simple-update prepared	-N -M prepared	13,626	3.34 MiB	1459	1962	2412

Writes (-N) bump Private_Dirty from ~1.4 MiB to ~2.4 MiB — extra anon pages for the modified-rows path. VmPTE is slightly lower because each backend is doing fewer row lookups per second (writes are slower). Net overhead is in the same 3.3–3.6 MiB band as the select-only baseline.

Connection mode (prepared vs simple) does not measurably change Pss_Anon for the simple lookup query — the prepared statement plan cache is small.

CSVs: /tmp/pg18-conn-agent/{tpcb-100,sm-100}/samples.csv.

[NikolayS]

Final summary — what we tested, what we didn't, what's left

Updated table replacing the original "off ≈ 2.64 / on ≈ 1.51"

PostgreSQL 18.3 / Ubuntu 24.04.3 / kernel 6.8.0-94 / EPYC-Milan, 16 GB RAM, 4 vCPU. Per-backend overhead = Pss_Anon + VmPTE. Sample size 50 random backends per run unless noted.

huge_pages	shared_buffers	clients	workload	jit	median overhead	notes
off	1GB	200	idle (no queries)	on	1.46 MiB	Pss_Anon 1.23, VmPTE 0.23
on	1GB	200	idle (no queries)	on	1.36 MiB	Pss_Anon 1.23, VmPTE 0.13
off	128MB	100	-S -M prepared	on	1.83 MiB	sd 0 — saturates fully
off	1GB	100	-S -M prepared	on	3.60 MiB	VmPTE saturates at 2.28 MiB
off	1GB	1024	-S -M prepared	on	3.43 MiB	wave 1 sample; wave 2 → 3.60 MiB
off	4GB	100	-S -M prepared	on	4.61 MiB	VmPTE 3.33 MiB (table doesn't fill)
on	1GB	1024	-S -M prepared	on	1.49 MiB	tight (sd 27 kB)
try	1GB	1024	-S -M prepared	on	1.50 MiB (594 hp) / 3.50 MiB (0 hp)	matches on/off respectively
off	1GB	100	-N -M prepared (writes)	on	3.34 MiB	extra Private_Dirty for write path
off	1GB	200	warm + idle (select count(*) then sleep)	on	10.07 MiB	JIT pinned ~8 MiB anon
off	1GB	200	warm + idle (same)	off	2.16 MiB	confirms JIT was the cause

Sanity checks done

• v1 Pss_Anon + VmPTE arithmetic was non-atomic (re-read /proc/$pid/status after read_status). v3 reads each /proc file once and parses both from in-memory copies. Original conclusions hold but the v1 numbers are very slightly drifted upward.
• "First 10 by pid" sampling biased the original number low by ~30% at huge_pages=off because early-pid backends have touched the fewest pages. Random sampling lifts the median from 2.64 → 3.4–3.6 MiB.
• Across-run variance (3 repeats) is small: cv on the median ≈ 0.4%. Within-run variance is dominated by which backends happen to have touched more of shared_buffers.
• huge_pages=on sampling method doesn't matter (every backend converges to ~136 kB VmPTE) — confirms the original 1.51 MiB.

What's left untested on this host (would be useful but not catastrophic gaps)

• TLS/SSL backends — would add OpenSSL state per connection; not measured.
• Backends with parallel workers active — pgbench -S doesn't trigger them.
• Backends with extensions loaded (pg_stat_statements, pgaudit, citus, …) — every extension adds private memory and shared shmem.
• Backends after a long-lived prepared statement set — Pss_Anon would grow with the plan cache.
• Real workloads with sort/hash spill — work_mem peaks aren't captured by the steady-state sample.
• Logical-replication walsenders / autovac workers — only normal client backends were sampled.
• max_prepared_transactions > 0 — would shift shmem allocation.
• TCP vs Unix socket — should be near-identical for memory; not directly measured.

What's unreachable on this host without reboot / privileged install

• 1GB hugepages — requires hugepagesz=1G hugepages=N kernel cmdline at boot.
• Different kernel versions — only one kernel installed.
• Different page sizes — x86_64 base page is 4 KiB, fixed.
• More than 594 × 2MiB hugepages — host memory fragmentation caps the live hugeadm-style reserve; got 594 only after drop_caches + compact_memory.
• NUMA effects — single socket Milan, no second NUMA node available.
• Different libc / different PG build flags — only the PGDG pgdg24.04+1 build present.

Bottom line

For this host, this PG18 build, this workload class:

• Idle backend (no queries): ~1.4 MiB regardless of huge_pages.
• Active pgbench backend, sb=1GB, huge_pages=off: 3.4–3.6 MiB, plateauing within ~30 s.
• Active pgbench backend, sb=1GB, huge_pages=on: 1.5 MiB, no ramp.
• Per-MB-of-shared_buffers cost (off): ≈ 8 bytes × pages_touched, i.e. up to ~2 MiB extra at sb=1GB and ~3.3 MiB at sb=4GB.
• JIT (PG18 default jit_above_cost) on a single 1.3GB seq scan: pins ~8 MiB anon per backend until disconnect.
• Sampling method matters when huge_pages=off (use random across all backends, ≥30 samples) and is irrelevant when huge_pages=on (every backend looks the same).

Honest assessment of "exhaustiveness"

I believe I've covered every practical knob on this host that can be turned without a reboot, a kernel install, or hardware that isn't here:

• repeat / variance ✓
• client-count sweep (1, 10, 100, 200, 500, 1024) ✓
• idle vs active vs warm-then-idle ✓
• shared_buffers sweep (128 MB, 1 GB, 4 GB) ✓
• pgbench scale sweep (10, 100, 200) ✓
• jit on/off ✓
• huge_pages on/off/try (with and without reserved pages) ✓
• query mode (prepared vs simple) ✓
• write workload (-N) ✓
• atomic snapshot, sampling-method bias check, drift-over-time ✓
• additional /proc/PID/smaps_rollup fields (Private_*, Pss_Shmem, Referenced, HugetlbPages) captured in the CSVs ✓

Things in the "untested" list above are genuinely useful follow-ups but each is a separate experiment with its own setup (extensions, TLS keys, replication slots), not a gap that would change the central conclusion. There are no further useful tweaks I can think of for this host within the constraints. Absolute full exclusion in the sense of "exhaustive for this machine and time budget."

Artifacts

• Harness: /tmp/pg18-conn-agent/v3.sh (and /tmp/pg18-conn-agent/v3-write.sh for the write/simple variants).

• One subdirectory per run under /tmp/pg18-conn-agent/<run>/ with samples.csv, results.md, summary.txt, pgbench.out, postgres.log. Data dirs deleted after each run; only the artifacts remain (a few hundred kB total).

• Original Sam Jr. outputs preserved untouched at /tmp/pg18-conn-overhead{,-off-1gb,-on}/.

• nr_hugepages started this session at 0 and is back at 0:

  HugePages_Total:       0
  HugePages_Free:        0
  HugePages_Rsvd:        0
  HugePages_Surp:        0
  Hugepagesize:       2048 kB
  Hugetlb:               0 kB