Linux 7.0 導致 PostgreSQL 效能崩潰：搶佔機制退化問題深度解析

背景

這起事件源於 AWS 工程師 Salvatore Dipietro 在 Linux 7.0 核心開發郵件清單中提交的補丁。他在配備 96 個 vCPU 的 Graviton4 機器上測試 PostgreSQL 時發現，由於 Linux 7.0 移除傳統伺服器預設的 PREEMPT_NONE 選項，改以 PREEMPT_LAZY 取代，導致 PostgreSQL 在高負載下的吞吐量驟降約 50%。這項效能衰退的核心原因在於核心搶佔機制的改變，使得資料庫內部的自旋鎖（Spinlock）在競爭激烈時，因持有鎖的進程被核心中斷，導致其他進程陷入無效的循環等待。

社群觀點

針對這項嚴重的效能倒退，Hacker News 社群展開了多層次的討論。部分開發者認為這反映了 Linux 核心維護風格的爭議，有人聯想到林納斯·托瓦茲（Linus Torvalds）過去對開發者的嚴厲斥責，認為這種破壞使用者體驗的變更理應受到嚴厲批評。然而，也有反對意見指出，對貢獻者進行羞辱性攻擊會打擊開發動力，且這類問題往往涉及極其複雜的歷史背景與架構權衡，並非單純的低級錯誤。

在技術層面上，社群成員敏銳地指出這項效能崩潰與特定的系統配置密切相關。有評論分析指出，該基準測試是在關閉「巨型分頁」（Huge Pages）且記憶體高達 120GB 的極端環境下進行的。在這種配置下，鎖競爭問題會從原本的效能瓶頸演變成災難性的衰退。雖然有觀點質疑 AWS 為何在測試中使用非典型配置，但也有資深工程師反駁，巨型分頁在歷史上曾有穩定性疑慮，導致許多維運人員習慣性地將其關閉，因此這並非罕見的邊緣案例。

此外，關於「基準測試」的真實性也引發了辯論。部分留言認為這僅是合成測試下的極端數據，未必代表真實世界的應用場景，建議核心開發團隊應先觀察是否有實際生產環境受損，再決定是否回退變更。但支持 PostgreSQL 的開發者強調，pgbench 模擬的是真實的 SQL 負載，其反映的鎖競爭問題在高度並行的資料庫應用中非常具有代表性。這場討論最終聚焦於一個核心矛盾：核心開發者追求架構的簡化與現代化，但資料庫等高效能軟體卻極度依賴舊有的核心調度行為來維持吞吐量。

延伸閱讀

在討論串中，有使用者分享了相關的技術討論連結，提供讀者進一步追蹤此問題在 Linux 核心郵件清單（LKML）中的後續進展：
https://news.ycombinator.com/item?id=47644864