北京时间 2026 年 4 月初，开源社区爆出一个值得所有 PostgreSQL 生产环境管理员警惕的信号：一位 Amazon AWS 工程师在 Linux 内核邮件列表中报告，Linux 7.0 开发版导致 PostgreSQL 在 AWS Graviton4 实例上的吞吐量下降至原有水平的约 51%，相当于性能被 “腰斩”。更令人担忧的是，问题根因已被定位，但上游维护者认为修复可能不会回退，而是建议 PostgreSQL 自身适配新的内核行为。这一技术冲突意味着，未来两周内即将正式发布的 Linux 7.0 稳定版，以及紧随其后发布的 Ubuntu 26.04 LTS，都可能对运行在云端的大量 PostgreSQL 实例产生显著影响。本文将深入技术细节，解析问题根因，提供可落地的评估参数与多层级应对策略。

抢占模型简化：从三种选项到两种选择

理解这一性能回归的关键在于把握 Linux 7.0 对内核抢占模型（Preemption Model）的重大修改。在 Linux 6.x 时代，内核提供了四到五种抢占模式供构建时选择，包括 PREEMPT_NONE（完全不可抢占，适用于服务器场景）、PREEMPT_VOLUNTARY（自愿抢占）、PREEMPT（完全抢占，降低延迟）以及 PREEMPT_RT（实时抢占补丁）。这些选项允许系统管理员和发行版维护者根据工作负载特性选择最合适的调度策略。

然而，Linux 7.0 对这一设计进行了大规模简化。内核维护者 Peter Zijlstra 主导的修改将可用抢占模式大幅缩减，对于使用现代 CPU 架构的系统，默认仅保留 PREEMPT_FULL（完全抢占）和 PREEMPT_LAZY（延迟抢占）两种模型。这一变更的初衷是减少内核维护负担、统一调度器行为，并推动更精细的时间片扩展机制。但正是这一看似合理的重构，在特定工作负载下暴露了深层问题。

问题的核心在于 PostgreSQL 这类数据库服务器软件长期依赖 PREEMPT_NONE 模式下的调度特性。在不可抢占的内核态执行路径中，数据库的后端进程可以长时间持有锁而不被调度器强制挂起，这对于高并发的 OLTP 事务处理至关重要。当抢占模式被强制切换到 PREEMPT_LAZY 时，内核调度器在检测到长时间运行的内核代码路径时会主动介入，这种抢占行为在用户空间的自旋锁（spinlock）保护区域产生了意外的交互。

技术根因：用户空间自旋锁与内核抢占的冲突

AWS 工程师 Salvatore Dipietro 在报告中详细描述了问题表现。在使用 pgbench 进行简单更新测试时（1024 并发客户端），Linux 7.0 在 AWS Graviton4 处理器上的 PostgreSQL 17 吞吐量下降至约 0.51 倍。通过二分查找法（bisect）精确定位，问题出在内核花费更多时间停留在用户空间的自旋锁等待中。

这一现象的技术解释如下：在 PREEMPT_NONE 模式下，即使内核代码执行了可能导致阻塞的操作，调度器也不会强行切换当前进程。这对于 PostgreSQL 这样的多进程数据库系统非常重要，因为每个客户端连接通常由一个独立的 postgreSQL 后端进程服务，而这些进程之间通过共享内存和自旋锁进行同步。当某个进程在持有自旋锁的状态下进入内核态并执行了可能触发调度的操作时，在 PREEMPT_NONE 模式下它可以继续运行直到释放锁，从而保证了锁持有者的快速退出，减少了其他进程的等待时间。

切换到 PREEMPT_LAZY 模式后，内核调度器的行为发生了变化。在某些特定的内核代码路径中，调度器会检查当前进程是否已经消耗了过长的时间片，如果是则会触发抢占。这意味着持有自旋锁的进程可能在不恰当的时机被挂起，导致锁被长时间占用，反而加剧了锁争用。对于 PostgreSQL 这种对锁竞争极度敏感的工作负载，这种抢占行为构成了性能瓶颈。

值得注意的是，这种影响并非在所有硬件平台上均匀呈现。AWS 工程师的测试在 Graviton4（ARM 架构）上复现了这一问题，而 Phoronix 的报道也提及该问题可能与特定的 CPU 微架构相关。这并不意味着 x86_64 平台完全免疫，而是可能需要特定的触发条件（如更高的并发数、更复杂的查询混合）才能暴露问题。

生产环境评估参数：你的系统是否在受影响范围内

面对这一潜在的性能回归，生产环境管理员需要迅速建立评估机制。以下是一套可直接用于检测的回溯性参数：

首先，硬件平台是最关键的筛选条件。截至 2026 年 4 月，AWS 上的 Graviton2、Graviton3 和 Graviton4 实例均可能受到影响，其中 Graviton4 由于采用了最新的 ARMv8.6+ 架构和不同的内存层级，对内核调度变化更为敏感。如果您在 AWS 上运行 PostgreSQL 且使用 ARM 实例，应立即在测试环境中复现压测。

其次，工作负载类型决定了受影响的程度。典型的 OLTP 事务处理场景（高并发、简单查询、频繁的短事务）最容易暴露问题，这是因为这类负载需要频繁的锁获取与释放，与抢占模型的交互最为密切。相比之下，OLAP 场景（复杂查询、大规模扫描）本身就涉及较长的执行时间，对锁争用的敏感度较低，可能不会显现显著的吞吐量下降。

第三，并发连接数是关键的触发参数。根据 AWS 工程师的报告，问题在 1024 并发客户端的 pgbench 测试中明显显现。生产环境中的连接池配置如果接近或超过这一数量级，应当重点关注。在实际业务中，许多部署使用 PgBouncer 或 RDS Proxy 等连接池中间件，这将连接数从应用层与数据库层解耦，可能掩盖问题，但这不意味着性能损失不存在 —— 只是被中间件吸收了部分。

第四，内核版本的具体构建变体同样重要。Ubuntu 26.04 LTS 将随附 Linux 7.0 稳定版，但不同发行版可能对内核配置进行了不同的定制。部分云服务商可能已经 backport 了相关修复或提供了替代的内核包。管理员应当明确当前运行的内核版本（uname -r）并对比上游代码变更。

评估时建议采集的基础指标包括：pgbench 测试的每秒事务数（TPS）及其在升级前后的变化、事务延迟的 P99 百分位、CPU 利用率分布（特别是 sys 和 iowait 比例）、上下文切换次数、以及 PostgreSQL 内部的锁等待统计（pg_stat_activity 中的 state 列）。如果 TPS 下降超过 20% 且伴随自旋锁等待时间上升，则高度可能受到了此问题影响。

多层级应对策略：从内核配置到数据库适配

面对这一性能回归，行业提供了多条应对路径，管理员可根据自身的技术栈和运维约束选择合适的方案。

第一层：内核参数回退。 截至 4 月初，内核邮件列表中已出现恢复 PREEMPT_NONE 作为默认抢占模式的补丁请求。该补丁由 AWS 工程师提交，试图将默认配置恢复至原有的服务器友好模式。然而，Peter Zijlstra 在邮件中明确表示倾向于不进行回退，而是推动 PostgreSQL 侧采用 RSEQ（Restartable Sequences）时间片扩展机制。这意味着上游可能不会接受该补丁，因此依赖内核默认配置恢复的方案存在不确定性。

如果您的环境可以自定义内核启动参数或使用自定义内核，可以考虑显式指定 preempt=none（或对应您发行版的参数）。这需要验证您的发行版内核是否仍然提供 PREEMPT_NONE 编译选项。在某些基于 Ubuntu 或 Debian 的系统中，可能需要切换到 low-latency 或 server 内核 flavor。

第二层：发行版层面的规避。 Ubuntu 26.04 LTS 将于 4 月晚些时候发布，默认搭载 Linux 7.0。对于已经在生产环境中运行 Ubuntu 22.04 LTS 或 24.04 LTS 的用户，如果没有紧急需求，可以考虑延迟升级或锁定内核版本。部分云服务商可能会提供经过测试的内核更新，管理员应当关注 AWS、Canonical 或其他云提供商的安全公告和内核更新说明。

对于必须运行新内核的场景，可以考虑在测试环境预先部署 Ubuntu 26.04 并运行 pgbench 基准测试，验证是否出现性能回归。如果出现问题，可能需要等待上游或发行版发布针对性的修复。

第三层：PostgreSQL 侧的自适应优化。 上游维护者 Peter Zijlstra 明确指出，推荐的长期解决方案是让 PostgreSQL 使用 RSEQ（Restartable Sequences）时间片扩展机制。该机制在 Linux 5.8 中引入，并在 Linux 7.0 中得到了进一步增强，允许用户空间代码在与内核协作的情况下更精细地控制时间片使用，减少锁持有者被抢占的风险。

目前，PostgreSQL 尚未完全适配这一机制。社区可能需要在后续版本中添加 RSEQ 支持。对于生产环境管理员，这意味着未来在升级 PostgreSQL 版本时应当关注其内核兼容性说明，并在测试环境中验证新版本在您特定的内核版本上的表现。

第四层：实例类型与架构的权衡。 鉴于问题在 Graviton4 上表现最为明显，如果您的基础设施允许，可以考虑在问题解决前将受影响的 PostgreSQL 工作负载迁移至 x86_64 架构实例（如 r7i、m7i 系列）。虽然这不是长期解决方案，但在性能与稳定性冲突的场景下，保持业务连续性优先于架构标准化。

另一个可行的方向是评估 AWS RDS for PostgreSQL 的托管服务。AWS 可能会在托管数据库层面应用内核补丁或配置调整，将这一复杂性从用户侧隐藏。如果您的团队运维能力有限，使用托管服务可能是更稳妥的选择。

持续监控与回滚预案

无论选择哪种应对策略，建立完善的监控和回滚机制都是必须的。在内核升级后的 72 小时内，建议执行以下监控动作：

持续采集 pgbench 或业务压测的 TPS 和延迟数据，与升级前的基线进行对比。设置告警阈值 —— 如果 TPS 下降超过 15% 或 P99 延迟增加超过 30%，应触发运维响应。监控 PostgreSQL 的内部指标，特别是锁等待时间（pg_stat_activity 中 wait_event_type 为 Lock 的会话比例）和上下文切换次数（通过 top 或 /proc/stat 获取）。

回滚预案应当包括：保留一个运行旧内核的等效实例作为对照、在升级失败时可以快速切换的数据库复制节点、以及应用层的流量切换能力。对于关键业务系统，建议采用蓝绿部署策略，先在新内核上运行只读查询负载，验证无异常后再切换写入流量。

总结： Linux 7.0 的抢占模型简化导致 AWS Graviton4 上 PostgreSQL 出现约 50% 的性能回归，这是一个在特定硬件和工作负载下触发的系统性交互问题。虽然上游倾向于通过 PostgreSQL 侧的 RSEQ 支持来解决，但短期内生产环境需要依赖内核参数调整、发行版选择或实例迁移等方式规避。关键在于：在 Ubuntu 26.04 LTS 发布前的窗口期完成评估，在内核升级后建立严格的性能监控，并准备好回滚预案。

资料来源： Phoronix 报道《AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy》（2026 年 4 月 4 日），Linux 内核邮件列表补丁讨论及 Peter Zijlstra 回复。