AWS工程师报告称Linux 7.0导致PostgreSQL性能下降一半，但修复可能并不容易。该问题已引起关注，但目前尚未找到简单解决方案。

AWS工程师报告Linux 7.0导致PostgreSQL性能减半，修复可能不易

主要内容：
亚马逊/AWS工程师Salvatore Dipietro发现，Linux 7.0开发内核在Graviton4服务器上运行PostgreSQL时，吞吐量降至之前内核版本的约51%。性能下降的原因是用户空间自旋锁的耗时显著增加。

问题根源：
通过排查，问题追溯到Linux 7.0对内核抢占模式的限制。该变更此前已在Phoronix报道中提及（Linux 7.0将仅支持完整和懒惰抢占模式），并随Linux 7.0调度器更新合并到主线。

修复尝试与争议：
工程师提交了补丁以恢复默认的PREEMPT_NONE抢占模式，但原作者Peter Zijlstra认为解决方案应是让PostgreSQL适配Linux 7.0新增的“可重启序列（RSEQ）时间片扩展”功能（相关报道）。Zijlstra指出，该功能可减少锁持有者被抢占的影响，除非PostgreSQL存在严重设计问题。

影响与时间线：
若此争议未解决，Linux 7.0稳定版（预计两周内发布）可能导致PostgreSQL在部分场景下性能显著下降，直至数据库软件完成适配。该内核版本也将成为Ubuntu 26.04 LTS（4月下旬发布）的基础。

图表说明：
文中附带的pgbench性能测试图直观展示了Linux 7.0与之前版本在PostgreSQL负载下的吞吐量差异。

（注：原文中的广告、导航栏、作者介绍及无关新闻链接等内容已按需删减，核心技术细节和争议焦点均保留。）

总结评论内容：

1. 关于内核变更对Postgres性能影响的争议

• 支持Postgres立场：认为50%性能下降是严重问题，内核不应破坏用户空间 "a 50% hit to performance of a pre-eminent database engine is ... quite the regression" "It's not a good look to break userspace applications without a deprecation period"

• 支持内核立场：建议Postgres适配新机制，生产环境可调整配置解决 "the fix is for Postgres to start using this new mechanism" "nobody running PG in production should be afraid of setting a non-default"

2. 技术解决方案讨论

• 建议Postgres服务构建时关闭抢占功能 "turn off pre-emption if your kernel is 7.0 or later"
• 指出用户空间自旋锁需要内核支持 "using spinlocks in user space at all without kernel support is just asking for weird performance"

3. 其他相关讨论

• 包含FreeBSD性能对比的调侃 "makes me feel better about the 10% performance regression"
• 对Linux内核维护流程的质疑（疑似玩笑） "Anyone check to see if Jia Tan has submitted any kernel patches lately?"

注：所有评论均无评分数据，主要反映开发者社区对Linux 7.0抢占机制变更的不同看法。核心争议在于内核变更是否应保持用户空间兼容性，以及性能下降的严重程度认定。