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 的 logical_decoding_work_mem 不是“越大越好”，而是要卡在 WAL 解析吞吐与内存安全的平衡点上。设太高，单个逻辑复制槽（replication slot）可能吃光 shared_buffers 外内存，触发 out of memory；设太低，解码器反复 flush 中间状态，CPU 和 I/O 反而飙升，延迟拉高。

• 默认值 64MB 对小事务量库够用，但只要单事务修改行数 > 50 万，或批量 UPDATE/DELETE 频繁，就大概率触发 ERROR: out of memory 或日志里反复出现 logical decoding worker restarting
• 建议起步值按「峰值变更行数 × 每行平均开销 128B」粗估，例如单事务改 200 万行 → 至少预留 256MB；再加 20% 余量防碎片
• 不能全局无脑调高：该参数是 * 每个 * decoding worker 独立分配的，一个 slot 启多个 worker（如并行 apply 场景）会乘倍消耗

和 work_mem、maintenance_work_mem 有什么区别？

这三个参数名字像，但作用域和触发时机完全不同：work_mem 控制排序、哈希等 SQL 执行内存；maintenance_work_mem 用于 VACUUM、CREATE INDEX；而 logical_decoding_work_mem 只服务于 WAL 解析阶段——即从磁盘读出 WAL 记录后，在内存里反序列化成 logical change（INSERT/UPDATE/DELETE 元组），再打包发给客户端（如 Debezium、pg_recvlogical）。

• 它们互不共享，也不会叠加生效；调高 logical_decoding_work_mem 对查询性能无直接影响
• 但如果复制下游消费慢，WAL 积压会导致 pg_wal 目录暴涨，此时 maintenance_work_mem 不足会让后续 VACUUM 失败，间接拖垮 decoding —— 所以得一起盯
• 线上曾见把 logical_decoding_work_mem 设到 2GB，结果单个 slot 占用 RSS 超 3.5GB，OS 开始杀进程；最后压回 512MB + 增加下游并发消费线程才稳住

怎么验证当前值是否合理？

别只看 SHOW logical_decoding_work_mem，关键看运行时行为。PostgreSQL 本身不暴露 decoding 内存实时用量，但可通过组合指标交叉判断：

• 查日志：grep "logical decoding worker restarting" 或 "out of memory" —— 出现就是硬性超限，必须降负载或提配额
• 监控 pg_replication_slots 视图里的 restart_lsn 和 confirmed_flush_lsn 差距：持续拉大（> 100MB WAL）说明 decoding 卡住，可能因内存不足频繁重试
• 用 pg_stat_activity 看 decoding 进程状态：若长期处于 active 但 backend_start 时间很新（几分钟内反复重启），基本可断定内存抖动

PG 14+ 并行 decoding 下的特殊注意点

PG 14 引入并行 logical decoding（通过 max_logical_replication_workers 和 slot 级参数控制），这时 logical_decoding_work_mem 是 * 每个 worker* 的上限，不是总和。容易误判成“我只开了 2 个 worker，设 1GB 应该没问题”，实际是 2 × 1GB = 2GB 瞬时需求。

• 并行模式下，worker 之间不共享 decode 缓冲区，各自独立解析 WAL segment 片段，内存无法复用
• 如果下游消费能力弱，多个 worker 会同时堆积未发送变更，总内存占用 = worker 数 × logical_decoding_work_mem ×（平均积压程度）
• 实测发现：PG 15 在高并发写入下，即使 logical_decoding_work_mem=256MB，开启 4 个 worker 后 RSS 峰值仍突破 1.2GB；最终改成 2 worker + 384MB 更稳

调优这事没法一锤定音，得盯着 pg_replication_slots、系统 RSS、错误日志三块数据来回比对；尤其要注意 PG 小版本升级后 decoding 内存模型的细微变化——比如 PG 15.4 修复了一个 buffer 未及时释放的 bug，同样配置下内存占用直接降了 30%。