本文字数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/s100基准的 80%400 MB/s500基准的 50%250 MB/s1,000基准的 20%100 MB/s降低写入速度可以减少 WAL 的生成速率让归档程序有喘息之机。由于该机制完全运行在数据面即使控制面故障或网络中断数据库也能实现自我保护。避免误伤恢复机制全局限流会产生副作用拖慢那些负责恢复系统状态的关键进程例如清理队列的归档进程、允许删除旧 WAL 的检查点进程checkpointer甚至是归档程序依赖的日志进程。为此我们将 cgroup 划分为两组。Postgres 进程会根据其名称声明角色负责清理积压的进程被归入不受限的“免疫组”而客户端后端进程则进入“受限组”。系统仅限制后者的写入读取操作则始终不受限。实际效果演示为了验证其实际效果我们在 EC2 实例上模拟了归档积压场景观察系统的应对能力。测试环境配置如下• 服务器 m7i.2xlarge8 vCPU32 GB运行 Ubuntu 24.04 与 Postgres 16。• 数据盘 专用 gp3 卷预置 500 MB/s 带宽。以此为限流基准对应的各级带宽上限分别为 400、250 和 100 MB/s。• 限流配置 直接采用生产环境配置由 15 秒周期的 systemd 定时器执行。Postgres 单元开启了 Delegateyes 以管理子 cgroup。• 模拟存储故障 通过 archive_command 将归档速率限制在 4 MB/s约每秒 0.25 个 WAL 段。第 20 分钟时移除限制模拟存储恢复。• 测试负载 使用 pgbench 执行 simple-update48 个客户端scale 为 300持续运行 35 分钟。事件时间线如下• 测试开始前 由于批量导入数据WAL 积压已超过 100 个段因此 t0 时 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 TPS50% 时为 11,800 TPS20% 时为 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 rbpsmax wbps104857600 riopsmax wiopsmax值得注意的是该测试负载产生的数据几乎全是 WAL且提交操作由不受限的 WAL writer 执行。因此限流对业务吞吐量的削减幅度远大于对 WAL 生成速度的限制后者仅下降约 10%。这种机制为磁盘争取了宝贵的缓冲时间具体时长取决于写入操作的数据密集度。总结牺牲暂时的性能换取的是实例永不因写入过载而崩溃。限流层级会根据阈值精准触发确保数据刷盘路径全程全速运行并在积压清理后立即自动解除。该功能已在所有 ClickHouse 托管 Postgres 服务器中默认开启。关于我们ClickHouse 是面向 AI 时代打造的高性能实时分析数据库能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台加速释放数据价值推动智能化创新与数字化转型。目前Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。