研究用 eBPF 解释云数据库的隐性写回停顿 RSS

NTT 的研究用 eBPF 追踪云端 PostgreSQL 的写回路径，发现每个块设备的单一回写线程可能来不及排出脏页，进而触发前台写入限流，而普通磁盘统计难以直接呈现这些停顿。实验在 PostgreSQL 16.4、Linux 5.14 和相同总 IOPS、带宽配置下比较一、二、四块云盘。论文报告，四盘布局相对单盘减少约 70% 的限流停顿，吞吐提高约 23%，最大事务延迟降低约 59%。这些结果提示排障时还应检查内核写回并行度。

发布于 2026-09-15T00:08:49.628528Z · Mitsumasa Kondo · arXiv / NTT

存储 性能 研究

NTT 的研究用 eBPF 追踪云端 PostgreSQL 的写回路径，发现每个块设备的单一回写线程可能来不及排出脏页，进而触发前台写入限流，而普通磁盘统计难以直接呈现这些停顿。实验在 PostgreSQL 16.4、Linux 5.14 和相同总 IOPS、带宽配置下比较一、二、四块云盘。论文报告，四盘布局相对单盘减少约 70% 的限流停顿，吞吐提高约 23%，最大事务延迟降低约 59%。这些结果提示排障时还应检查内核写回并行度。

NTT 的研究用 eBPF 追踪云端 PostgreSQL 的写回路径，发现每个块设备的单一回写线程可能来不及排出脏页，进而触发前台写入限流，而普通磁盘统计难以直接呈现这些停顿。实验在 PostgreSQL 16.4、Linux 5.14 和相同总 IOPS、带宽配置下比较一、二、四块云盘。论文报告，四盘布局相对单盘减少约 70% 的限流停顿，吞吐提高约 23%，最大事务延迟降低约 59%。这些结果提示排障时还应检查内核写回并行度。

原始来源 ↗

来源记录

• pgweb.info_item · 68c5746f6de1a278 · 2026-10-03T04:08:55.967155Z