■ 1. 問題の概要
- Linux 7.0の開発カーネル上でPostgreSQLのスループットが約半減する性能劣化が報告された
- AWSのエンジニア サルヴァトーレ・ディピエトロが2026年4月3日にLinuxカーネルメーリングリストへ報告
- テスト環境はAWS EC2 m8g.24xlarge（Graviton4 / 96 vCPU）でPostgreSQL 17を使用
- pgbench（simple-update / 1024クライアント / 96スレッド / 1200秒）の結果:
- Linux 7.0（PREEMPT_LAZY）ベースライン: 約50,751 TPS
- 問題コミットをリバート後（PREEMPT_NONE相当）: 約98,565 TPS（1.94倍）
- perfプロファイリングにより CPU時間の55%がPostgreSQLのユーザースペーススピンロック（s_lock）で消費されていることが判明
■ 2. 原因
- Linux 7.0 rc1で導入されたカーネルスケジューラの変更が根本原因
- Intelのカーネルエンジニア ペーター・ジルストラによるコミットが利用可能なプリエンプションモードを制限
- 従来はサーバー向けに「PREEMPT_NONE」（プリエンプションなし・スループット最大化優先）が存在していた
- Linux 7.0でx86・ARM64等の主要アーキテクチャからPREEMPT_NONEが廃止され「FULL」と「LAZY」の2モードのみに変更
- 目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進
- PostgreSQLはプロセスモデルを採用し共有メモリへのアクセスにユーザースペーススピンロックを多用する
- PREEMPT_LAZY環境ではロック保持中にタスクが中断される頻度が上がり他のプロセスが無駄にスピンし続ける結果となった
■ 3. カーネル開発者の対応方針
- ディピエトロはPREEMPT_NONEをデフォルトに戻すパッチを提出したが受け入れられなかった
- ジルストラはPostgreSQL側がRSEQ（Restartable Sequences）のタイムスライス拡張を活用すべきと回答
- タイムスライス拡張はLinux 7.0で利用可能になったカーネル機能
- アプリケーションがスケジューラに対してタスク切り替えの延期を要求できる仕組み
- リバートの見込みは薄く修正責任はPostgreSQL側に求められている
- PostgreSQLがRSEQのタイムスライス拡張を採用するにはコード変更が必要であり実現時期は不透明
- 少なくともLinux 7.0のリリースには間に合わない状況
■ 4. タイムラインと影響範囲
- Linux 7.0安定版リリースは4月中旬を予定
- Ubuntu 26.04 LTSのリリースは4月23日を予定
- Linux 7.0はUbuntu 26.04 LTSのカーネルとして採用予定
- LTSは企業・サーバー環境で広く使われるためPostgreSQL運用組織への影響が懸念される
- 今回のテスト条件は96 vCPU・1024クライアントという高負荷環境であり全構成で同影響が出るわけではない
- AWSのGraviton4のような大規模インスタンスはPostgreSQLの主要な運用環境であり影響を受ける環境は少なくない
■ 5. 過去の類似事例とパターン
- PostgreSQLとLinuxカーネルの性能摩擦は今回が初めてではない
- 2010年: Linux 2.6.32のEXT4 fsync変更によりPostgreSQLの性能が大幅低下
- 2008年: CFSスケジューラ導入後にpgbenchのリグレッションが報告
- カーネル開発者はシステム全体の設計改善を優先し特定アプリケーション向けの最適化を「アプリ側の責任」とする構造的パターンが繰り返されている
- Phoronixが2月に実施したLinux 7.0のAMD EPYCベンチマークではPostgreSQLの読み書き性能が大幅に向上していたとの報告もあり プリエンプションモデルの変更は環境やワークロードによって正反対の影響を与えうる