SQL logical_decoding_work_mem 的逻辑复制内存预算调优经验

logical_decoding_work_mem需按峰值变更行数×128B估算并加20%余量，如200万行建议256MB；它独立作用于每个decoding worker，与work_mem、maintenance_work_mem互不干扰。 logical_decoding_work_mem 设置多大才不爆 OOM？ PostgreSQL 的 不是“越大越好”，而是要卡在 WAL 解析吞吐与内存安全的平衡点上。设太高，单个逻辑复制槽（replication slot）可能吃光 shared_buffers 外内存，触发 ；设太低，解码器反复 flush 中间状态，CPU 和 I/O 反而飙升，延迟拉高。 默认值 对小事务量库够用，但只要单事务修改行数 > 50 万，或批量 UPDATE/DELETE 频繁，就大概率触发 或日志里反复出现 建议起步值按「峰值变更行数 × 每行平均开销 128B」粗估，例如单事务改 200 万行 → 至少预留 ；再加 20% 余量防碎片 不能全局无脑调高：该参数是 *每个* decoding worker 独立分配的，一个 slot 启多个 worker（如并行 apply 场景）会乘倍消耗 和 work_mem、maintenance_work_mem 有什么区别？ 这三个参数名字像，但作用域和触发时机完全不同： 控制排序、哈希等 SQL 执行内存； 用于 VACUUM、CREATE INDEX；而 只服务于 WAL 解析阶段——即从磁盘读出 WAL 记录后，在内存里反序列化成 logical change（INSERT/UPDATE/DELETE 元组），再打包发给客户端（如 Debezium、pg_recvlogical）。 它们互不共享，也不会叠加生效；调高 对查询性能无直接影响 但如果复制下游消费慢，WAL 积压会导致 目录暴涨，此时 不足会让后续 VACUUM 失败，间接拖垮 decoding —— 所以得一起盯 线上曾见把 设到 ，结果单个 slot 占用 RSS 超 3.5GB，OS 开始杀进程；最后压回 + 增加下游并发消费线程才稳住 怎么验证当前值是否合理？ 别只看 ，关键看运行时行为。PostgreSQL 本身不暴露 decoding 内存实时用量，但可通过组合指标交叉判断： 查日志：grep 或 —— 出现就是硬性超限，必须降负载或提配额 监控 视图里的 和 差距：持续拉大（> 100MB WAL）说明 decoding 卡住，可能因内存不足频繁重试 用 看 decoding 进程状态：若长期处于 但 时间很新（几分钟内反复重启），基本可断定内存抖动 PG 14+ 并行 decoding 下的特殊注意点 PG 14 引入并行 logical decoding（通过 和 slot 级参数控制），这时 是 *每个 worker* 的上限，不是总和。容易误判成“我只开了 2 个 worker，设 1GB 应该没问题”，实际是 2 × 1GB = 2GB 瞬时需求。 并行模式下，worker 之间不共享 decode 缓冲区，各自独立解析 WAL segment 片段，内存无法复用 如果下游消费能力弱，多个 worker 会同时堆积未发送变更，总内存占用 = worker 数 × × （平均积压程度） 实测发现：PG 15 在高并发写入下，即使 ，开启 4 个 worker 后 RSS 峰值仍突破 1.2GB；最终改成 2 worker + 更稳 调优这事没法一锤定音，得盯着 、系统 RSS、错误日志三块数据来回比对；尤其要注意 PG 小版本升级后 decoding 内存模型的细微变化——比如 PG 15.4 修复了一个 buffer 未及时释放的 bug，同样配置下内存占用直接降了 30%。