Linuxカーネル7.0の開発版で導入されたスケジューラ変更が、PostgreSQLの高並列ワークロードで大きな性能低下を引き起こしている。AmazonのSalvatore Dipietro氏は2026年4月3日、Linux Kernel Mailing Listに対し、v7.0-rc1で入ったコミット7dadeaa6e851「sched: Further restrict the preemption modes」が原因で、PostgreSQLのpgbench simple-updateにおけるスループットとレイテンシが悪化したと報告し、PREEMPT_NONEを既定値に戻すパッチを投稿した。
報告された低下幅は大きい。arm64環境のAWS EC2 m8g.24xlarge、すなわちGraviton4ベースの96 vCPU構成で測定したところ、問題の変更を含むベースラインは平均50,751.96、変更を差し戻した構成では平均98,565.86となった。差し戻し後の結果はベースライン比で1.94倍に達しており、現状のLinux 7.0系では、特定条件下のPostgreSQL性能がほぼ半減する計算になる。
注目すべきなのは、原因候補が比較的明確であるにもかかわらず、修正方針が割れている点である。AWS側はカーネル既定値の差し戻しを提案したが、スケジューラ変更の当事者であるPeter Zijlstra氏は、修正の本筋はPostgreSQL側がrseqのslice extensionを使うことだと応じた。今回の論点は性能回帰そのものにとどまらない。汎用OSの既定動作が既存アプリケーションとの互換性をどこまで負うのか、逆にアプリケーション側が新しい実行モデルへどこまで追従すべきなのかが、同時に問われている。
問題の起点はLinux 7.0-rc1でのプリエンプションモード変更
Dipietro氏の報告によれば、回帰の起点はLinux 7.0-rc1で入った、利用可能なプリエンプションモードをさらに制限する変更である。投稿タイトル自体がRestore PREEMPT_NONE as defaultである通り、AWS側の当面の対処案は、既定のプリエンプション設定を従来寄りの状態へ戻すことだった。
今回の性能低下で鍵になっているのは、PostgreSQLのユーザー空間スピンロックが、現行のプリエンプション挙動と組み合わさったときに待ち時間を大きく膨らませている点である。Dipietro氏は性能プロファイルを示し、StartReadBufferからGetVictimBuffer、StrategyGetBufferへ至る経路の中で、CPU時間の55%がPostgreSQLのuserspace spinlock (s_lock())で消費されていると説明した。全体が少しずつ遅くなったのではなく、特定の競合ポイントにCPU時間が集中していることが、今回の回帰を特徴づけている。
プリエンプション設定の変更そのものは、カーネル側から見れば実装の整理として説明できる。しかし、データベースのように高並列で動き、ロック保持側の実行タイミングが性能へ直結するソフトウェアでは、既定値の変更がアプリケーションの同期コストへ鋭く反映されることがある。今回の事例は、その影響が想定以上に大きかったことを示している。
AWSが示した再現条件は限定的だが、無視しにくい
Dipietro氏が挙げた再現環境は、一般的な小規模運用とはかなり異なる。ハードウェアはAWS EC2 m8g.24xlarge、ストレージは12x 1TB IO2 32000 iops RAID0 XFS、OSはAL2023、カーネルはnext-20260331、データベースはPostgreSQL 17である。ワークロードはpgbench simple-update、1024 clients、96 threads、1200秒、scale factor 8470、fillfactor=90、prepared protocolという、高並列かつ競合が出やすい条件でそろえられている。
そのため、この数値をそのまま「すべてのPostgreSQL環境が半減する」と一般化するのは適切ではない。今回の測定は、高負荷時のボトルネックを表面化させやすい条件で取られており、実運用のすべてが同じ割合で悪化するとは限らない。ソースが示しているのも、あくまでこの構成でのsimple-update負荷の結果である。
それでも見過ごしにくい理由は二つある。第一に、報告者が回帰の原因候補をコミット単位まで絞り込んでいることだ。単に「新しいカーネルで遅い」と述べているのではなく、どの変更がどの種の待ちを増やしたかを、プロファイル付きで示している。第二に、ベンチマークが人工的な条件を含んでいても、ロック保持者のプリエンプトが性能を崩す構造自体は、高並列データベース処理では十分に現実的な問題であることだ。とりわけ高コア数のarm64サーバーでは、こうしたボトルネックが一気に顕在化しやすい。
ベンチマーク結果は図で見ても差が大きい
公開された表では、ベースライン3回の結果が47,242.39、53,369.18、51,644.29で平均50,751.96、差し戻し構成は92,906.62、103,976.03、98,814.94で平均98,565.86だった。ランごとの揺らぎはあるが、両者の差は誤差では説明できない。
以下の比較グラフを見ると、ベースライン構成と差し戻し構成の開きは視覚的にも明確であり、既定のプリエンプション設定変更が高並列ワークロードへ与えた影響の大きさが分かる。
差し戻し後が1.94xということは、元の構成は差し戻し後の約半分しか性能を出せていないことになる。Phoronixが「ほぼ半減」と報じた表現はやや強めではあるが、AWSの投稿に示された平均値とは整合している。
争点は差し戻しか、PostgreSQL側の適応か
この報告に対し、Peter Zijlstra氏は同日中に返信し、修正策はPREEMPT_NONEを既定に戻すことではなく、PostgreSQLがrseq slice extensionを利用することだと述べた。返信では、「The fix here is to make PostgreSQL make use of rseq slice extension」としており、それによってlock holder preemptionへの露出を抑えられるという見方を示している。
この返答から見えてくるのは、カーネル開発側が今回の事象を「カーネルが既存動作を壊した問題」ではなく、「アプリケーションが新しい実行モデルに適応しきれていない状態」と捉えている可能性である。Phoronixは、Linux 7.0にはそのtime slice extension supportもすでに取り込まれていると伝えており、少なくともZijlstra氏の立場では、対処不能な退行ではない。
一方、AWS側の提案は利用者影響を優先する発想に近い。広く使われる既存データベースが、カーネル更新だけで大きく性能を落とすのであれば、まず既定値を戻して影響範囲を抑えるべきだという考え方である。保守系ディストリビューションやクラウド事業者がこうした判断を重視するのは自然であり、アプリケーション側の追従を待つ間に利用者が性能低下を受けるなら、そのコストは小さくない。
両論にはそれぞれの合理性がある
AWSの提案が支持を集めやすいのは、被害の見え方が明快だからである。既定値の変更後に、広く使われているソフトウェアで大きな性能回帰が生じた。そうであれば、まず変更を戻すべきだという主張は理解しやすい。
ただし、Zijlstra氏の立場にも合理性はある。カーネルの既定動作を新しい方向へ進めたいのであれば、既存アプリケーションとの衝突が起きるたびに全面的な差し戻しを繰り返していては、実行モデルの更新は進みにくい。特に、今回のように原因が「ロック保持者がプリエンプトされる時間をどう減らすか」という比較的具体的な形で説明できるなら、アプリケーション側に新機構の採用を促す判断にも筋は通る。
難しいのは、その最適化コストを誰が負担するかである。PostgreSQLがrseqの新拡張へ対応すれば長期的には整合的かもしれないが、実装、検証、リリースには時間がかかる。その間にLinux 7.0系が安定版として出荷されれば、ユーザーは「仕様としては成立しているが、従来より遅い」状態を引き受けることになる。
本質は責任論よりも、移行コストをどこへ置くかにある
この論点は、LinuxカーネルとPostgreSQLのどちらが悪いかという単純な責任論では整理しにくい。AWSの報告は、既定のプリエンプション変更がPostgreSQLの高競合パスに大きく効いたことを示している。Zijlstra氏の返信は、その脆さを減らす技術的な手段がPostgreSQL側にもあると示した。両者の主張は対立しているようで、実際には優先する時間軸が異なる。
短期では、既存アプリケーションの性能を大きく崩さないことが重視される。この観点では差し戻し案が有力である。中長期では、新しい同期支援機構をアプリケーション側が取り込み、カーネル側の設計自由度を高める方向が視野に入る。今回の衝突は、その短期と長期の優先順位がまだ一致していないことを示している。
とりわけクラウド事業者にとって、この種の問題はベンチマークの数字だけで終わらない。Gravitonのような高コア数arm64サーバーは、性能効率を武器に採用が進んできた。その上で、メジャーカーネル更新が代表的なデータベースのスループットを大きく揺らすなら、OS選定、カーネル更新計画、マネージドサービスの検証コストまで波及する。これはソースを踏まえた分析になるが、今回の議論が早い段階で表面化したのは、この移行コストが大きいからだと見るのが自然である。
Linux 7.0の最終判断だけでなく、その後の適応も焦点になる
Phoronixは、Linux 7.0の安定版が約2週間後に迫っており、4月後半に出るUbuntu 26.04 LTSでもこの系統のカーネルが使われると伝えている。実際にそのまま出荷されるかは今後の議論次第だが、時間的な余裕が大きくないことは、この問題を難しくしている。
もし既定値の差し戻しが採用されれば、Linux 7.0は「一度入れた実行モデル変更を、主要ワークロードへの影響を見て引き戻したリリース」として整理されるだろう。逆に差し戻しが見送られれば、Linux 7.0は「新しい前提を採る代わりに、一部アプリケーションへ適応を促すリリース」になる。どちらの道を選んでも、利用者にとっての意味はかなり異なる。
今回のニュースの核心は、Linux 7.0でPostgreSQLが遅くなったことそのものだけではない。その性能低下に対して、カーネル側とアプリケーション側が異なる出口を見ている点にある。差し戻しで当面の互換性を守るのか、PostgreSQLがrseq拡張を取り込み、新しい前提へ寄せていくのか。次に注目すべきなのはLinux 7.0の最終判断に加え、PostgreSQLコミュニティ、ディストリビューション、クラウド事業者がこの移行コストをどう分担するかである。
Sources