比“女孩心思”更难猜, PG 并行 I/O 到底该配几个 Worker？

最难猜的不是“女孩的心思”, 而是 PG 的并行 I/O 该配几个 Worker

深夜，一条告警打破了平静——数据库 I/O 延迟飙升。DBA 翻了翻监控，发现队列里积压了大量 I/O 请求，Worker 全在忙，CPU 却没打满。问题指向了一个你可能从没调过、但调了就头疼的参数：io_workers。这就是 PostgreSQL 19 重点解决的核心问题之一。

1个参数引发的"玄学调参"

io_workers 控制 PostgreSQL 异步 I/O 子系统的 Worker 进程数，默认 3，取值范围 1~32。

这个参数难在哪？

• 3 个太少：批量写入时 I/O 排队，后端进程空等；
• 32 个太多：夜间空闲时 Worker 全空转，浪费内存和调度资源；
• 业务潮汐：白天繁忙、夜间空闲，固定数量永远无法两全；
• 改了还得等：增大 worker 数要 reload，减少 worker 数要重启或等异常退出。

DBA 们普遍靠经验猜测，结合压测反复调整——这不是工程问题，这是玄学。

PostgreSQL 19 的答案是：别猜了，让 Worker 自己决定规模。

PostgreSQL 19 做了什么

PostgreSQL 19 在 AIO 子系统中引入了自适应 Worker 池，将原来的静态参数 io_workers 替换为 4 个新参数，Worker 数量根据 I/O 队列积压情况自动伸缩：

工作原理一句话概括：

I/O 积压超过当前 Worker 数 → 自动扩容；最高编号 Worker 空闲超时 → 自动退出。

3 个设计细节值得关注

① 扩容看排队深度，不是经验值

Worker 每次醒来，如果发现队列积压深度超过当前 Worker 总数，就向 Postmaster 请求启动新 Worker。这个判断完全基于实测数据，而不是 DBA 的经验猜测。

② 只有"最高编号"才能退出

Worker 池始终保持 0, 1, 2, … 的连续编号。收缩时，只有编号最高的空闲 Worker 才会超时退出——这样设计保证了池不会留下"空洞"，也不会意外跌破 io_min_workers 的硬下限。

③ 虚假唤醒自己会停

Worker 统计"被唤醒次数"和"实际处理 I/O 数"的比值。如果一个 Worker 频繁被叫醒但没干什么活，说明已经到了唤醒链的末端，它会停止继续叫醒同伴，让更多 Worker 安心睡觉。这个机制显著减少了无意义的 CPU 消耗。

实际效果对比

以夜间批量导入场景为例：

效果：零人工干预，资源消耗始终与负载匹配。

怎么配置

PostgreSQL 19 默认参数（2~8 个 Worker，60s 空闲超时）已经能覆盖大多数场景。如果需要个性化调整：

-- 保守策略（资源受限环境）
ALTERSYSTEMSET io_min_workers = 1;
ALTERSYSTEMSET io_max_workers = 4;
ALTERSYSTEMSET io_worker_idle_timeout = '30s';

-- 激进策略（高吞吐混合负载）
ALTERSYSTEMSET io_min_workers = 4;
ALTERSYSTEMSET io_max_workers = 16;
ALTERSYSTEMSET io_worker_idle_timeout = '120s';

PostgreSQL 18 的 io_workers 参数在 19 中已被移除，升级后需要重新配置。

一句话总结

PostgreSQL 19 把 AIO Worker 池从"人工静态配置"升级为"数据驱动的自适应系统"——不再靠猜，而是让队列深度告诉你该有多少 Worker 在跑。

建议：升级到 PostgreSQL 19 后，先用默认参数观察一段时间，再根据实际负载做微调。

你还在为 PostgreSQL 调参头疼吗？有哪些参数让你纠结过？欢迎留言区聊聊。