PG用户怒了，Linux 7.0 新内核导致数据库性能暴跌50%
digoal约 4 分钟PG用户怒了，Linux 7.0 新内核导致PG性能暴跌50%
Linux 7.0 还没正式发布，PostgreSQL 用户先炸了。
AWS 工程师在 2026 年 4 月初 发现：同样的 PostgreSQL 压测，在 Linux 7.0-rc1 上，跑在 AWS Graviton4 服务器时，吞吐量只剩下旧内核的大约 一半。这不是“轻微波动”，而是非常扎眼的 50% 级性能下滑。
这事为什么会引爆社区？因为它踩中的不是一个冷门场景，而是数据库最核心的命门之一： 锁竞争。
先说结论：不是 PostgreSQL 变慢了，是内核调度逻辑变了
这次问题被定位到 Linux 内核调度器的一次改动。
过去，在不少场景下，内核对“正在运行中的任务”没那么激进，尤其对数据库这类高并发程序来说，这种行为其实很友好。原因很简单：
PostgreSQL 内部有大量非常短、非常频繁的 spinlock（自旋锁） 临界区。
谁先拿到锁，谁就应该尽快干完，立刻放锁。
只要这个过程足够短，整体吞吐就很高。
但 Linux 7.0 这条内核线在现代架构上，把抢占模型进一步收敛，默认更偏向 PREEMPT_LAZY 这一类更“公平”的调度方式。结果就是：
拿着锁的 PostgreSQL 线程，更容易在关键时刻被切走。
一旦持锁者被切走，其他 PostgreSQL 线程怎么办？
答案是： 疯狂空转等锁。
锁没释放，别人又不停自旋，CPU 看起来很忙，实际没干多少有效工作。于是你看到的现象就出现了：
CPU 使用率很高 PostgreSQL 吞吐暴跌 机器看起来没闲着，但业务就是慢了
这就是典型的“公平性提高了，吞吐却掉了”。
这事为什么特别像数据库人的噩梦？
因为数据库和普通应用不一样。
对桌面系统、Web 服务、通用负载来说，调度更公平，往往意味着响应更平滑，系统体验更均衡。
但对 PostgreSQL 这种高并发数据库来说，很多时候最怕的不是“不公平”，而是：
“拿着锁的人被抢占。”
你可以把它想象成一个收费站：
一个收费员已经拿到了闸机钥匙 他只差 1 秒就能把车放过去 这时管理员说：不行，为了公平，你先下去休息，换别人来
问题是，钥匙还在他手里。
后面所有车都堵住了。
Linux 内核想解决的是“所有人都别独占时间片”；
PostgreSQL 想要的是“谁拿了锁，先让他把这几步做完”。
两边都没错，但目标不一样，于是冲突就出来了。
社区怎么回应？更精彩的地方在后面
PostgreSQL 社区的第一反应很现实：
先把旧行为恢复回来。
原因也很直接。时间点非常敏感：
Linux 7.0 稳定版临近发布 Ubuntu 26.04 LTS 也临近发布 一旦进入主流发行版，影响会迅速放大
这时候让 PostgreSQL 立刻重写底层并发策略，基本不现实。
但 Linux 内核社区的态度是：
不要回退全局策略，应该让 PostgreSQL 去适配新的机制。
他们给出的方向是： rseq time slice extension。
你可以把这个机制理解成：
“应用先告诉内核，我马上要进入一个特别短、特别关键的临界区，先别那么快切我。”
听起来很合理，对吧？
但问题在于，PostgreSQL 社区并不喜欢这个答案。因为这意味着：
PostgreSQL 需要专门适配新接口 代码复杂度会上升 后续维护成本也会上升 而且这类底层绑定，不是所有数据库社区都愿意接
说白了，这就像工作里最常见的一句话：
“先别动底层规则，你们业务先兼容一下。”
听起来熟悉不？
这件事最值得普通 PG 用户警惕什么？
不是“Linux 7.0 一定不能用”。
而是你要知道：
内核升级，不只是驱动升级，不只是安全补丁升级，它可能直接改掉 PostgreSQL 的性能曲线。
特别是这些场景，要高度警惕：
高并发 OLTP 热点更新多 CPU 核数多 ARM 大核服务器 PostgreSQL 锁竞争本来就偏重
这种情况下，调度器策略一变，性能可能不是掉 5%、10%，而是直接掉到让人怀疑人生。
所以如果你是 DBA、架构师、云上 PG 用户，接下来最应该做的不是吵架，而是两件事：
升级新内核前，先压测 PostgreSQL 重点看热点锁、自旋、上下文切换和吞吐变化
别等系统都升完了，线上才发现“CPU 很忙，但 TPS 没了”。
最后一句
这不是 PostgreSQL 和 Linux 谁对谁错的问题。
这是一个非常典型的系统工程冲突：
Linux 想让系统更通用、更公平 PostgreSQL 想让锁持有者尽快跑完，换更高吞吐
站在各自立场都说得通。
但对 PG 用户来说，结果只有一个：
新内核如果处理不好，性能真的会暴跌 50%。
这才是最扎心的地方。