Linux 7.0でPostgreSQL性能半減、修正困難か
カーネルの設計変更が、世界で最も使われるデータベースの一つを直撃している。修正パッチは出されたが、カーネル開発者の回答は「アプリ側で対処せよ」だった。
カーネルの設計変更が、世界で最も使われるデータベースの一つを直撃している。修正パッチは出されたが、カーネル開発者の回答は「アプリ側で対処せよ」だった。
PostgreSQLのスループットが半分になった
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)の平均スループットは約5万751。問題のコミットをリバートした場合の平均は約9万8565で、1.94倍の改善が確認された。スループット比で0.51倍という数字は、同じハードウェア上で性能がほぼ半減したことを意味する。
つまり、リバートすればほぼ倍の性能が戻る。この差は「誤差」で片付けられる規模ではない。
perfプロファイリングの結果、CPU時間の55%がPostgreSQLのユーザースペーススピンロック(s_lock)で消費されていることが判明した。PREEMPT_LAZY環境下で、ロック競合が劇的に悪化している。
原因はプリエンプションモデルの制限
問題の根源は、Linux 7.0のrc1で導入されたカーネルスケジューラの変更にある。Intelのカーネルエンジニア、ペーター・ジルストラが作成したコミットが、利用可能なプリエンプションモードを制限した。
従来、Linuxカーネルはサーバー向けに「PREEMPT_NONE」(プリエンプションなし)というモードを提供していた。スループット最大化を優先し、カーネルがタスクを途中で中断しない設計だ。データベースサーバーのように、CPUを長時間占有する処理には理想的なモードだった。
Linux 7.0では、x86やARM64などの主要アーキテクチャでPREEMPT_NONEが選択肢から消えた。「FULL」と「LAZY」の2モデルのみに絞られ、目的はカーネルの簡素化とPREEMPT_RT(リアルタイム対応)への統合推進だが、その副作用がPostgreSQLを直撃した形になる。
PostgreSQLはプロセスモデルを採用しており、共有メモリ上のデータ構造へのアクセスにユーザースペーススピンロックを多用する。PREEMPT_NONE環境では、スピンロックを保持中にプリエンプション(タスク切り替え)が起きないため、ロック保持時間が短く済む。PREEMPT_LAZYに変わったことで、ロック保持中にタスクが中断される頻度が上がり、他のプロセスが無駄にスピンし続ける結果になった。
プリエンプション(preemption)とは、OSがCPU上で実行中のタスクを強制的に中断し、別のタスクに切り替える動作のこと。レスポンス向上には有効だが、データベースのようにロック競合が激しい環境では性能低下を招きうる。
カーネル開発者の回答──「PostgreSQLが変わるべき」
ディピエトロはPREEMPT_NONEをデフォルトに戻すパッチを提出したが、プリエンプションモード変更の作者であるジルストラの反応は異なった。
ジルストラは、PostgreSQLがRSEQ(Restartable Sequences)のタイムスライス拡張を活用すべきだと指摘した。タイムスライス拡張はLinux 7.0で利用可能になったカーネル機能で、アプリケーションがスケジューラに「今はタスク切り替えを少し待ってほしい」と要求できる仕組みだ。
この回答が意味するのは、リバートの見込みは薄く、修正の責任がPostgreSQL側に求められているということだ。これは技術的には筋が通っている。RSEQのタイムスライス拡張はまさにこの種の問題を解決するために設計されたものだ。
だが、現実的な問題がある。PostgreSQLがRSEQのタイムスライス拡張を採用するには、PostgreSQL側のコード変更が必要になる。その変更がいつ実現するかは不透明で、少なくともLinux 7.0のリリースには間に合わない。
要するに「修正する方法は存在するが、すぐには使えない」状態だ。カーネルは予定通りリリースされ、PostgreSQLの性能劣化はユーザーが引き受けることになる。
Ubuntu 26.04 LTSへの波及
この問題にタイムリミットがある理由は明快だ。Linux 7.0の安定版リリースは4月中旬、Ubuntu 26.04 LTSのリリースは4月23日を予定している。
LTS(Long Term Support)は企業やサーバー環境で広く使われる。Linux 7.0はUbuntu 26.04 LTSのカーネルとして採用される予定であり、PostgreSQLをUbuntu上で運用している組織にとって、カーネルアップグレードと同時にデータベース性能が半減するリスクは看過できない。
もちろん、テスト条件は96 vCPU・1024クライアントという高負荷環境であり、すべての構成で同じ影響が出るわけではない。しかし、AWSのGraviton4のような大規模インスタンスはまさにPostgreSQLの主戦場だ。影響を受ける環境は決して少なくないだろう。
繰り返されるカーネルとPostgreSQLの摩擦
PostgreSQLとLinuxカーネルの間の性能摩擦は、今回が初めてではない。2010年にはLinux 2.6.32のEXT4 fsync変更でPostgreSQLの性能が大幅に低下し、2008年にはCFSスケジューラ導入後にpgbenchのリグレッションが報告された。
パターンはいつも同じだ。カーネル開発者はシステム全体の設計改善を優先し、特定のアプリケーションの振る舞いに合わせた最適化は「アプリ側の責任」とする。アプリケーション開発者は、長年安定していた前提条件が突然変わることに困惑する。
今回の件でひとつ注目すべきは、皮肉にもPhoronixが2月に行ったLinux 7.0のAMD EPYCベンチマークでは、PostgreSQLの読み書き性能が大幅に向上していたという報告があることだ。プリエンプションモデルの変更は、環境やワークロードによって正反対の影響を与えうる。
Linux 7.0の安定版リリースまで残り1〜2週間。このまま修正なしで出荷されるのか、それとも何らかの緩和策が間に合うのか。少なくとも、PostgreSQLをLinux 7.0で運用する予定があるなら、自分の環境でベンチマークを取ることを強く勧める。
参照元
他参照
関連記事
- トーバルズ、Linux 7.0来週リリースへ rc7で最終確認
- Rust Coreutils 0.8が登場、dd 45%高速化とブラウザ実行環境
- 悪意あるUSBを検出するLinuxカーネルドライバが登場
- Gentooのエイプリルフールがガチだった件──36年越しのカーネルが動く
- Ubuntu 26.04 LTSが最小RAM要件を6GBに引き上げ――価格高騰の真っ只中に
- BUS1がRustで復活──LinuxカーネルIPC再挑戦
- GNOME 50がGoogle Driveを切り捨てた理由
- Metaが暴いた/proc/interruptsの隠れたボトルネック
- Ubuntu MATE創設者が12年の歴史に区切り──後継者不在のまま幕引きへ
- Linux 7.0-rc6直前、EXT4に異例の大量バグ修正が投入された