ClickHouse 托管 Postgres 的 WAL 背压机制与实现原理

关注

原创最新推荐文章于 2026-11-08 16:01:54 发布 194 阅读 AI 写同款· GEO 优化 ›

CentOS 7 离线升级 OpenSSH 9.9p2 保姆级教程（含依赖包下载与常见报错解决）本文提供了一份详尽的CentOS 7系统离线升级OpenSSH至9.9p2版本的完整教程。针对无外网环境，重点讲解了依赖包（尤其是OpenSSL 3.x）的离线下载与编译部署，并深入解决了编译过程中常见的“libcrypto.so缺失”等动态库链接错误。教程涵盖从环境准备、源码编译、服务配置到系统集成的全流程，最后还提供了关键的回滚方案与应急预案，是运维人员在内网环境中进行安全加固的实用指南。阅读详情

本文字数：3081；估计阅读时间：8分钟

作者：Kaushik Iska

编者按： 本文译自 ClickHouse 原博客。原文围绕「数据库自动化运维中的流量整形与自我保护机制」展开。通过在数据面引入基于 I/O 控制器的背压机制，ClickHouse 实现了对 WAL 积压风险的闭环控制。这种设计有效平衡了系统吞吐量与数据安全性，为托管数据库服务的稳定性提供了参考。

什么是 WAL 归档？我们又为何要刻意限制数据库的写入速度？在数据持久化到表文件之前，Postgres 的所有变更都会先记入预写式日志（WAL）。ClickHouse 托管的 Postgres 会将写满的 WAL 段上传至对象存储，以支持按时间点恢复（PITR）。只有上传成功，Postgres 才能安全地删除相应的日志段。如果写入速度持续超过归档程序的上传速度，WAL 就会不断堆积并耗尽磁盘空间。Postgres 会将磁盘写满视为 PANIC 错误，直接导致实例宕机。

来自数据面的背压

ClickHouse 托管 Postgres 引入了背压（backpressure）机制来解决这一问题。系统利用 systemd 定时器每 15 秒统计一次积压的日志段数量，并通过 cgroup v2 I/O 控制器动态调整 Postgres 的写入带宽上限。该上限基于磁盘预置吞吐量的比例设定，并随积压程度加深而自动收紧：

积压的日志段数	写入上限	假设磁盘基准为 500 MB/s
100	基准的 80%	400 MB/s
500	基准的 50%	250 MB/s
1,000	基准的 20%	100 MB/s

降低写入速度可以减少 WAL 的生成速率，让归档程序有喘息之机。由于该机制完全运行在数据面，即使控制面故障或网络中断，数据库也能实现自我保护。

避免误伤恢复机制

全局限流会产生副作用，拖慢那些负责恢复系统状态的关键进程：例如清理队列的归档进程、允许删除旧 WAL 的检查点进程（checkpointer），甚至是归档程序依赖的日志进程。为此，我们将 cgroup 划分为两组。Postgres 进程会根据其名称声明角色，负责清理积压的进程被归入不受限的“免疫组”，而客户端后端进程则进入“受限组”。系统仅限制后者的写入，读取操作则始终不受限。

实际效果演示

为了验证其实际效果，我们在 EC2 实例上模拟了归档积压场景，观察系统的应对能力。测试环境配置如下：

• 服务器： m7i.2xlarge（8 vCPU，32 GB），运行 Ubuntu 24.04 与 Postgres 16。

• 数据盘：专用 gp3 卷，预置 500 MB/s 带宽。以此为限流基准，对应的各级带宽上限分别为 400、250 和 100 MB/s。

• 限流配置：直接采用生产环境配置，由 15 秒周期的 systemd 定时器执行。Postgres 单元开启了 Delegate=yes 以管理子 cgroup。

• 模拟存储故障：通过 archive_command 将归档速率限制在 4 MB/s（约每秒 0.25 个 WAL 段）。第 20 分钟时移除限制，模拟存储恢复。

• 测试负载：使用 pgbench 执行 simple-update，48 个客户端，scale 为 300，持续运行 35 分钟。

事件时间线如下：

• 测试开始前：由于批量导入数据，WAL 积压已超过 100 个段，因此 t=0 时 80% 的限流已生效，挂起段数为 224 个。批量加载是导致归档滞后的典型场景。

• 第 1.9 分钟：积压量突破 500，带宽上限降至 50%。

• 第 4.7 分钟：积压量突破 1,000，带宽上限降至 20%。此时积压量以每分钟约 170 个段的速度增长，产生约 45 MB/s 的 WAL 数据。

• 第 0-20 分钟： pgbench 吞吐量随限流等级逐级下降。初始爆发值为 22,000 TPS，在 80% 限流下降至 12,800 TPS，50% 时为 11,800 TPS，20% 时为 9,600 TPS。

• 第 20 分钟：模拟存储恢复正常。此时积压量达到峰值（3,433 个段），占用了 53 GiB 的磁盘空间。

• 第 20-23.7 分钟：归档进程以磁盘全速清理积压，每分钟处理约 850 个段；与此同时，业务负载继续在限流状态下运行。

• 第 23.8 分钟：积压量降至 100 以下，定时器随后解除限流。pgbench 稳定在 12,200 TPS，归档速度恢复同步。

• 测试总结：数据盘利用率始终未超过 33%，且全程无需人工干预。

通过 cgroup 文件系统可以直观观察到这种进程分类。测试进行到 10 分钟时，不受限的 cgroup 准确包含了负责清理积压的进程链（基于进程名分配），包括由归档进程派生的 archive_command 子进程。48 个客户端进程则被限制在另一个 cgroup 中。查看 io.max 可见，20% 的限流仅针对写入操作生效：

== immune ==
4679  /usr/lib/postgresql/16/bin/postgres -D /dat/16/data
4680  postgres: 16/main: checkpointer
4681  postgres: 16/main: background writer
4683  postgres: 16/main: walwriter
4685  postgres: 16/main: archiver archiving 00000001000000000000009E
8354  pv -q -L 4m pg_wal/00000001000000000000009E

== throttled ==
4684  postgres: 16/main: autovacuum launcher
4973  postgres: 16/main: postgres bench [local] COMMIT
4974  postgres: 16/main: postgres bench [local] COMMIT
      ... 46 more client backends ...

$ cat throttled/io.max
259:1 rbps=max wbps=104857600 riops=max wiops=max

值得注意的是：该测试负载产生的数据几乎全是 WAL，且提交操作由不受限的 WAL writer 执行。因此，限流对业务吞吐量的削减幅度远大于对 WAL 生成速度的限制（后者仅下降约 10%）。这种机制为磁盘争取了宝贵的缓冲时间，具体时长取决于写入操作的数据密集度。

总结

牺牲暂时的性能，换取的是实例永不因写入过载而崩溃。限流层级会根据阈值精准触发，确保数据刷盘路径全程全速运行，并在积压清理后立即自动解除。该功能已在所有 ClickHouse 托管 Postgres 服务器中默认开启。

关于我们

ClickHouse 是面向 AI 时代打造的高性能实时分析数据库，能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构，ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台，加速释放数据价值，推动智能化创新与数字化转型。目前，Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。

收录于