Postgres服务器上还运行着什么？如何防止它拖垮数据库？

你的 Postgres 服务器的虚拟机上还运行着什么，又是什么阻止它拖垮数据库？除了 Postgres，我们的服务器还运行着几个 PgBouncer 实例、一个备份代理、指标导出器、一个本地 Prometheus、一个日志收集器，以及一些看门狗定时器。每个进程都在保护数据库。每个进程也都可能泄漏内存、耗尽 CPU 或填满磁盘。

这使得它们每一个都处于数据库的故障模型中。监控进程可能消耗 Postgres 所需的内存。备份代理可能使处理查询的 CPU 饱和。任一故障都可能导致整个实例宕机。

共享机器即共享内存

Postgres 有一个异常强大的边界。它的shared_buffers分配位于启动时保留的大页中，因此其他进程无法慢慢蚕食它。我们在关于为 Postgres 保留大页的文章中解释了为什么我们使该分配变得严格。

Postgres 还需要shared_buffers之外的内存。内核页缓存、每个后端的工作内存、连接状态以及大量较小的分配都来自与 PgBouncer、WAL-G、Prometheus、导出器和日志记录相同的机器级内存池。其中任何一个进程的泄漏都可能耗尽每个数据库后端所依赖的余量。

ClickHouse Managed Postgres 为辅助进程提供了明确的资源限制。四个 Go 服务、Prometheus、WAL-G 备份代理、postgres_exporter和node_exporter——运行在一个 cgroup v2 切片中。systemd 的MemoryHigh和MemoryMax属性写入该切片的memory.high和memory.max控制。每个服务还携带一个GOMEMLIMIT，其大小设置使得各个 Go 堆预算之和低于memory.high。

运行时和 cgroup 强制执行

这些边界的作用不同：

GOMEMLIMIT被特意作为第一道防线。Go 能比内核更上下文相关地反应：它知道哪些是堆、哪些是存活的，以及何时再来一次垃圾回收周期可能有帮助。接近预算的服务会做更多的回收工作，通常能自行保持在限制之内。

GOMEMLIMIT仍然是一个运行时目标。原生分配、存活对象或真正的泄漏可能使进程超出它。cgroup 提供内核强制：超过memory.high的计入进入回收和节流。

无法在memory.max以下回收的计入触发 cgroup OOM 事件。

Postgres 内存计入单独的 cgroup，因此辅助服务 cgroup 中的memory.max事件不会选择 Postgres 进程。

该切片的配额与我们的严格过度提交策略在 Postgres 份额之上预留的余量相同。提交预算保留内存；cgroup 将进程约束在预算内。这两个控制从相反方向描述同一容量。

所有资源的预算

一个进程可能在堆使用上表现完美，但在其他方面伤害数据库，因此同样的纪律延伸到整个虚拟机：

• 备份以默认 CPU 权重的一小部分运行，因此当机器繁忙时，前台数据库工作会获胜。
• WAL-G 的缓冲区是 RAM 的固定比例，使内存使用在工作负载增长时保持有界。
• 日志收集器有其自己的内存限制器，防止日志突发成为第二次事故。
• 离开机器的指标是经过精心挑选的，因此新标签不能悄悄地在内存、CPU 和网络流量方面造成无界基数账单。

现在每种资源都有一个强制点：CPU 使用调度器权重，内存使用固定缓冲区大小和 cgroup，磁盘使用本地阈值，导出的指标序列使用允许列表。

磁盘满会话豁免

Postgres 需要空闲磁盘才能继续前进，而数据卷满可能会迅速将普通工作负载变成可用性事件。在紧急阈值时，磁盘看门狗会终止会话以减少写入压力。有两个用户名被豁免终止：复制和监控。

终止并非不分青红皂白。看门狗读取pg_stat_activity并将每个后端的数据库用户名映射到保留或终止决策。

来自普通应用程序用户名的会话随后被终止，这立即移除了它们的写入路径。

复制豁免保持备用 WAL 流式传输活动。监控豁免在事件期间保持数据库指标对操作员和自动化可用。

备份代理获得有界的内存分配和较低的 CPU 权重。Prometheus 计入主机服务 cgroup。磁盘看门狗明确保留复制和监控角色。这些控制在定义的资源限制内保持备份、复制和可观察性可用。

由此产生的隔离模型

托管 Postgres 服务器是一个由协作进程组成的小型系统。可靠性取决于将每个辅助服务视为保护和潜在压力：为运行时提供它能够理解的预算，为内核提供它可以执行的上限，并让紧急路径保持在其要处理的故障之外。

这些控制在每台 ClickHouse Managed Postgres 服务器上默认启用。