2026 年 4 月上旬，距离 Linux 7.0 稳定版正式发布不足两周，AWS 工程师 Salvatore Dipietro 抛出了一枚技术炸弹：通过内核二分查找法，他定位到 Linux 7.0 导致 PostgreSQL 吞吐量骤降的具体提交 —— 在 AWS Graviton4 ARM 架构服务器上，新内核仅能达到旧版本 0.51 倍 的性能。这意味着数百万运行 PostgreSQL 的生产环境将在升级后面临性能腰斩的残酷现实。更值得关注的是，内核开发者的回应并非 “会考虑回退”，而是直截了当地告诉 PostgreSQL 社区：“去用 RSEQ。” 这一态度将内核与用户态应用之间的技术博弈推向了新的临界点。

抢占模型变更的技术本质

理解这场性能灾难，需要先弄清 Linux 7.0 在抢占调度层面做了何种架构决策。该版本对现代 CPU 架构（ARM64、x86、PowerPC、RISC-V、s390、LoongArch 等）移除了 PREEMPT_NONE 作为默认选项，此前这一模式允许内核在服务器工作负载下完全不进行抢占，从而最大化吞吐量。Linux 7.0 推出后，调度器仅提供 PREEMPT_FULL（完全可抢占，低延迟优先）和 PREEMPT_LAZY（调度器控制的延迟抢占）两种模式。

这一变更的初衷是推进 “根本可抢占”（fundamentally preemptible）内核的长期愿景。内核开发者认为，随着多核服务器场景日益复杂，统一的抢占模型能够简化调度逻辑，降低维护成本。然而，这种架构简化直接冲击了依赖非抢占语义的应用程序，PostgreSQL 正是受影响最严重的案例之一。

PostgreSQL spinlock 的脆弱性

PostgreSQL 的内部同步机制大量依赖用户态自旋锁（user-space spinlock）。这种轻量级锁的核心逻辑是：当锁不可用时，线程在一个紧凑循环中反复检查锁状态，而非立即挂起。在 PREEMPT_NONE 模式下，持有锁的线程不会被调度器打断，争夺锁的其他线程只需等待有限的时间即可获得锁 —— 这是服务器端数据库工作负载数十年来的基础假设。

然而，PREEMPT_LAZY 模型允许调度器在持有锁的线程执行关键代码期间进行抢占。当一个持锁线程被调度器强制换下时，其他所有等待该锁的线程陷入无意义的空转 —— 它们消耗 CPU 周期，却无法取得任何进展。这种 “锁持有者被抢占等待” 现象在大规模并发连接下被急剧放大，导致吞吐量断崖式下跌。

内核拒绝回退：架构理念与技术现实

面对 AWS 工程师的报告，Linux 内核核心维护者 Peter Zijlstra 的回应简洁而强硬：“The fix here is to make PostgreSQL make use of rseq slice extension…That should limit the exposure to lock holder preemption.” 这句话背后的含义是明确的：内核不打算为 PostgreSQL 回退 PREEMPT_NONE 的移除，问题的解决方案在于用户态应用主动适配。

Zijlstra 提到的 RSEQ（Restartable Sequences，可重试序列）是 Linux 7.0 同步引入的机制，允许用户态代码向内核请求 “时间片扩展”—— 在执行关键原子操作期间，持有锁的线程可以避免被调度器抢占。理论上，这正是为 PostgreSQL 这类依赖自旋锁的应用设计的解决方案。然而现实是：PostgreSQL 尚未集成 RSEQ 支持，社区也没有公布明确的时间表。对于正在生产环境中面临 50% 性能损失的 DBA 们，“等 PostgreSQL 适配” 是无法接受的答复。

产业影响与 DBA 的现实选择

性能下降 50% 意味着什么？对于运行 10 台 PostgreSQL 服务器的企业，升级 Linux 7.0 后若不采取措施，需要增加一倍的服务器数量才能维持原有的查询吞吐能力 —— 这直接对应云服务账单翻倍。AWS 自身也意识到了这一问题，其托管数据库服务（RDS PostgreSQL）很可能在问题解决前不会向客户推送 Linux 7.0 升级。但对于自管理 PostgreSQL 的用户，如果采用自动化内核更新策略，或在测试阶段使用了与生产不符的轻量级基准测试，这一回归将在升级后立即显现。

对于 DBA 群体，眼下最务实的策略是推迟生产环境的 Linux 7.0 升级，直至 PostgreSQL 社区发布 RSEQ 支持或内核侧出现有效的缓解补丁。具体操作层面，应在内核升级流程中加入 pgbench 或 sysbench 性能基准测试，监控自旋锁等待时间指标，并在生产环境锁定内核版本而非依赖自动更新。AWS RDS 等托管服务的用户可以依赖云厂商的测试流程，但自建数据库场景下这一责任完全落在运维团队肩上。

暴露的深层问题：内核测试与真实工作负载的脱节

这起事件最值得反思的点在于：PostgreSQL 作为全球部署最广泛的开源数据库之一，其核心工作负载特性在 Linux 7.0 的开发周期中竟未触发任何性能回归警报。根本原因在于内核测试矩阵的侧重点 —— 内核维护者依赖合成基准测试（lmbench、stream、perfnett 等）验证调度器行为，而真实应用栈（数据库、消息队列、分布式存储）的复杂并发模式不在其覆盖范围内。

这一脱节并非新问题。2014 年 PostgreSQL 社区就曾与内核开发者讨论过类似议题，但八年后的今天，历史以更尖锐的方式重演。当架构理念的演进与应用生态的适应速度不匹配时，受伤的总是依赖这些组件的一线工程师。

结语

Linux 7.0 抢占模型的变更本质上是内核架构的一次大胆简化，其设计目标在于长期的可维护性和统一的调度语义。然而，当这一变更与 PostgreSQL 的自旋锁假设正面碰撞时，50% 的性能跌幅揭示了内核与用户态之间微妙的依赖平衡正在被打破。内核方的立场是清晰的 ——“让应用适应”，但 PostgreSQL 社区能否以及何时完成 RSEQ 集成，仍然是一个未解的问题。对于生产环境的 DBA 们，眼下最稳妥的做法是握紧手中的内核版本号，在测试环境充分验证后再谈升级。

资料来源：AWS 工程师 Salvatore Dipietro 于 2026 年 4 月 3-4 日在社区的报告；Peter Zijlstra 在 LKML 上的回应；ByteOTA 相关报道。