Hacker News 中文摘要

RSS订阅

Linux 7.0导致PostgreSQL崩溃：抢占式回归问题解析 -- Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

原文链接 | HN讨论 | 2026-04-30 04:02:17

文章摘要

Linux 7.0内核版本导致PostgreSQL在96核Graviton4机器上的吞吐量下降约50%，原因是内核抢占机制的改变影响了PostgreSQL的内存管理方式，特别是内存页的处理。AWS工程师已提交修复补丁。

文章总结

标题：Linux 7.0如何拖累PostgreSQL性能：抢占机制退化的背后

核心内容：

2026年4月，AWS工程师Salvatore Dipietro发现，在96 vCPU的Graviton4机器上，Linux 7.0导致PostgreSQL吞吐量骤降至6.x版本的一半。通过性能分析工具perf检测，55%的CPU时间消耗在s_lock函数中，问题根源与Linux 7.0的抢占调度机制变更有关。

关键发现： 1. 性能对比
- Linux 6.x：98,565事务/秒
- Linux 7.0：50,751事务/秒

  1. 抢占模式变更
    Linux 7.0移除了PREEMPT_NONE选项（原服务器默认配置，以高吞吐量为特点），仅保留：

    • PREEMPT_FULL（激进抢占，桌面环境常用）
    • PREEMPT_LAZY（折中方案，6.12引入）

  2. PostgreSQL内存管理机制

    • 使用8KB数据页作为存储单元，通过120GB共享缓冲池缓存热数据
    • 多后端进程通过自旋锁竞争缓冲池访问权，锁持有期间若触发4KB内存页的缺页中断（约3100万次潜在中断），在PREEMPT_LAZY模式下可能被调度器抢占，导致其他进程长时间空转

解决方案：
启用大页（2MB/1GB）可将缺页中断降至6.1万次/120次，消除TLB压力，性能回归问题消失。但需注意： - 大页需预分配，可能造成内存浪费 - 需在PostgreSQL配置中显式设置huge_pages=on

争议：
内核开发者建议PostgreSQL采用重启序列（rseq）检测抢占，但社区更倾向恢复PREEMPT_NONE选项，认为不应为内核变更牺牲原有性能。

延伸阅读：
- 缺页中断与TLB机制
- Linux抢占模式演进史
- PostgreSQL缓冲池工作原理

（注：原文中的图片链接、代码片段及部分技术细节已精简，保留核心逻辑链条）

评论总结

以下是评论内容的总结：

  1. 问题严重性争议

    • 部分评论认为问题被夸大，实际只影响特定配置（评分：无）
      "This only happened under a very odd configuration... The headline implies it broke PG everywhere. It didn’t." (MBCook)
      "Moderators should change this headline because it is nowhere near true." (jeltz)

  2. 技术配置讨论

    • 焦点集中在禁用大页(hugepages)的非常规配置上（评分：无）
      "120GB RAM postgres with hugepages=off... amazon runs DB tests with huge pages disabled" (baq)
      "That regression is maybe most useful as a reminder to people to configure huge pages" (fabian2k)

  3. 性能与兼容性权衡

    • 关于内核改动是否值得的讨论（评分：无）
      "An X% performance regression is basically a (100 - X)% feature breakage" (dataflow)
      "I'd rather know if any real world usage broke... before changing the kernel" (buster)

  4. 解决方案争议

    • 对rseq方案的误解与澄清（评分：无）
      "The real proposal is about time-slice extension... has nothing to do with retrying critical sections" (singron)

  5. 开发流程批评

    • 对调度系统长期问题的反思（评分：无）
      "It only took a few decades for Linux to get a good CPU scheduler" (ahartmetz)
      "bad scheduling is everywhere... most developers seem to hate dealing with it" (ahartmetz)

  6. 其他关联事件

    • 提及近期内核更新导致的其他问题（评分：无）
      "Right on the heels of 6.19 breaking tcmalloc and Mongo" (nijave)
      "The last time a linux upgrade broke PG was the xz backdoor" (cachius)

保留关键引用格式：
英文原文 (作者)
对应中文

（注：所有评论均无评分数据，故未标注认可度；总结时已平衡不同观点，并保留最具代表性的2-3条引用）