What else runs on your Postgres server, and how do we stop it from taking the database down?

Summary

The Postgres VM described here runs PgBouncer instances, a backup agent, metrics exporters, a local Prometheus, a log collector, and watchdog timers alongside the database. Those processes share machine-wide resources outside Postgres’s huge-page-backed shared_buffers, so leaks, CPU saturation, or disk exhaustion can threaten database availability. ClickHouse Managed Postgres places supporting services in a cgroup v2 slice and combines Go runtime GOMEMLIMIT targets with systemd memory.high and memory.max enforcement. GOMEMLIMIT encourages earlier garbage collection, memory.high applies reclaim and throttling, and memory.max provides a hard ceiling whose OOM scope excludes Postgres because it uses a separate cgroup. CPU weights, bounded buffers, log and metric controls, disk thresholds, and exemptions for replication and monitoring sessions extend isolation across other failure modes; these controls are enabled by default.

Takeaways

1. 1

   GOMEMLIMIT gives Go services a runtime-level memory target, while memory.high triggers reclaim and throttling and memory.max supplies kernel-enforced cgroup OOM isolation.

2. 2

   Backup CPU weight is reduced and WAL-G buffers are fixed as a fraction of RAM, limiting backup pressure on foreground database work and bounding memory as workload grows.

3. 3

   At the disk emergency threshold, the watchdog terminates ordinary application sessions but preserves replication and monitoring sessions so WAL streaming and operational visibility remain available.