本文字数：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 支撑其关键业务和数据分析平台。
