effective_io_concurrency
Fact — 官方简述译文:设置单个会话可高效利用的存储并发度。
身份
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0(研究下界) |
| 在档版本 | PG9.0–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 不作断言:早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–17 | 1 |
— | 1 |
| PG18–19 Beta 3 | 16 |
— | 16 |
机制详解
effective_io_concurrency 告诉单个会话应尝试利用多少存储并发;它不是集群级队列上限。同名 tablespace 选项可针对该存储上的数据覆盖会话设置。
PG10–17 中它主要控制受支持路径与平台的预取距离。Linux-Docker 实测 boot 值为 1,但缺少有效 posix_fadvise、因而不受支持的平台上游默认是 0;任何历史默认值表述都必须带上该平台条件。
PostgreSQL 18 将该参数接入核心异步 I/O,boot 默认改为 16,并允许用 0 关闭由该目标控制的异步请求。io_max_concurrency 仍是独立的单进程执行上限,combine 参数则控制每次请求字节数。
调优建议
Advice。 以下建议是工作负载起点,必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 从保守值开始并在并发下测量读取延迟。短小点查通常不如位图扫描或扫描型负载受益,而高连接数下过高的每会话值会放大队列深度。 |
| OLAP | 分析扫描与位图堆扫描更可能从高值受益。尤其在网络存储或高 IOPS 设备上,应同时测试持续吞吐与尾延迟。 |
| 小规格 | 除非测量确认存在 I/O 停顿,优先采用 PG18 默认或适中值。小主机不会仅因磁盘标注为 SSD 就自然适合 200。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具,并按 PG19 Beta 3 渲染当前 Pigsty 模板;这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 200 |
不同于 boot 值 | 200 |
| OLAP | 200 |
不同于 boot 值 | 200 |
| CRIT | 200 |
不同于 boot 值 | 200 |
| TINY | 200 |
不同于 boot 值 | 200 |
Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 = 200 (dcs);OLAP: PG9.0–19 Beta 3 = 200 (dcs);CRIT: PG9.0–19 Beta 3 = 200 (dcs);TINY: PG9.0–19 Beta 3 = 200 (dcs)。 建议(待人工复核)——编辑推断:Pigsty 的 SSD 分支假设较深的会话级读取并发与预取有益;该假设必须在设备层验证。
常见坑
- 把该会话级目标误当成集群总上限;大量会话会放大未完成 I/O。
- 把 1 称为 PG10–17 无条件上游默认,忽略不支持平台默认 0。
- 把 PG18 AIO 行为套到主要用于预取建议的旧版本。
- 混合存储 tablespace 仍使用单一全局值,不考虑 tablespace 覆盖。
- 持续提高目标,直到设备排队拖慢所有会话。
关联参数
maintenance_io_concurrency · io_method · io_max_concurrency · io_combine_limit · random_page_cost · effective_cache_size
参考资料
- PostgreSQL 19 Beta 3 — effective_io_concurrency
- PostgreSQL 18 发行说明:异步 I/O 与新默认值
- PostgreSQL 19 发行说明
- 机器可读 GUC 全量导出