ハクソク

世界を動かす技術を、日本語で。

AWSエンジニアが報告：Linux 7.0によってPostgreSQLのパフォーマンスが半減、修正は容易ではないかもしれない

2026年4月5日原文(phoronix.com)

概要

  • Linux 7.0開発カーネル でPostgreSQLのスループットが約半分に低下
  • 原因は プリエンプションモードの制限 によるユーザースペーススピンロック滞留時間の増加
  • Amazon/AWSエンジニア がリグレッションを報告
  • カーネル側は PREEMPT_NONE 復活パッチを提案も採用は不透明
  • PostgreSQL側の対応 （RSEQ拡張利用）が推奨される流れ

Linux 7.0によるPostgreSQLパフォーマンス低下問題

  • Amazon/AWSのSalvatore Dipietro がLinux 7.0カーネルでのPostgreSQLの スループットとレイテンシの悪化 を報告
  • Graviton4サーバー上で 従来カーネルの約0.51倍 までスループットが減少
  • ユーザースペーススピンロック での待機時間が大幅に増加
  • 問題の原因は プリエンプションモード制限 （PREEMPT_NONE廃止）への変更
  • この変更は Linux 7.0スケジューラアップデート の一環として導入

カーネル開発側の対応と議論

  • Linux kernel mailing list でPREEMPT_NONEをデフォルトに戻すパッチが投稿
  • しかし、 Peter Zijlstra （元コード作者）は PostgreSQL側のRSEQ拡張対応 を推奨
  • RSEQ（Restartable Sequences）time slice extensionは Linux 7.0で上流化
  • 「PostgreSQLがRSEQ拡張を利用すれば、ロック保持者のプリエンプションの影響が軽減可能」との見解
  • カーネル側での根本的な巻き戻しは 現時点で否定的

今後への影響

  • PostgreSQLのアップデート が行われない限り、Linux 7.0安定版環境下で パフォーマンス低下が持続
  • Linux 7.0は Ubuntu 26.04 LTS などの基盤カーネルとしても採用予定
  • PostgreSQLユーザーは アップデートの必要性 や 回避策の検討 が求められる状況

参考リンク

Hackerたちの意見

アンドレス・フロイントが書いたこのLKMLのフォローアップポストは読む価値あるよ。彼はPostgresに関わってるからね。 https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqk...

└

「巨大ページを使え」っていうのがそこにあるのに、99%のユーザーが無視してるのが面白いね。

└

そのスレッドでは、「96コアのarm64マシンでパフォーマンスが0.51倍」と言っていて、96コアのamd64マシンでは再現できないとも言ってるみたい。だから、PostgreSQLを使っていて最新のカーネルにアップグレードする人全員に影響するわけじゃなさそう。条件は、arm64、大量のコア、カーネル7.0、PostgreSQLの現在のバージョンって感じかな。7.0が数週間後にリリースされても、全てのPostgreSQL DBに当てはまるわけじゃないよね。

└

これは単なる一つの投稿じゃなくて、スレッド全体を追うとさらに情報があるからね。 :)

└

もしこれが再現可能なパフォーマンスの問題になるとしたら（もっと複雑なことが起きている気がするけど）、ユーザースペースが7.0の重大なパフォーマンス低下をどうやって緩和できるのか、全く見当がつかないよ。7.0で追加されたデフォルトオフの非トリビアルな機能によってしか緩和できないのに。

昔、リーナスはカーネルがユーザースペースを「壊す」べきじゃないって叫んでたよね。最近は「壊れてない、ただパフォーマンスが落ちただけ」って意見も見かけるけど、個人的には一流のデータベースエンジンで50%のパフォーマンスダウンは…かなりの後退だと思う。今、Linux 7.0で導入された新しいプリエンプション処理メカニズムを紹介したカーネルエンジニアが、「修正」はPostgresがこの新しいメカニズムを使い始めることだと言ってる。下のコメントにPostgresのエンジニアの意見がリンクされてると思うけど、私はほぼ同意するかな。

└

50%のパフォーマンスダウンは…かなりの後退だと思う 確かに！特にその後退が取引や市場関連に影響を与える場合は…

└

面白い視点だね。「これは障害じゃなくて（水平または垂直の）劣化だ」っていうのはウェブサービス特有だと思ってたけど、考えてみるとこういうケースにも当てはまるんだね。

└

これが最初に思ったことだな。カーネルはソフトウェアを壊さない、少なくとも昔はそうだった。

└

他のメンテナが「リーナスの法則」に引っかかったのはこれが初めてじゃないよね。彼は、何が原因かがもっと分かるまで待っているのかもしれない。

└

彼がそれについて怒鳴る理由は、誰かがそれをやったからだよ。もし誰もやらなかったら、彼は決して怒鳴らないし、ルールもできなかっただろう。だから、これは誰かが線を引き続けなきゃいけないことなんだろうね。自動的に守られるルールじゃない。間違いなく、誰かが怒鳴る必要があるだろう。

常識のある人は最新のカーネルを使わないし、PGを本番環境で運用してる人はブート時やsysctlで非デフォルト設定をすることを恐れる必要はないよ。だから、これはPGデータベースサーバーを構築するためのもう一つのステップになると思う（カーネルが7.0以上でPGがそのバージョン以前ならプリエンプションをオフにする）。最悪の場合、PGサーバーを構築する際の恒久的な部分やFAQになるかもしれないけど、これが一つにこんなに悪影響を与えるなら、他にも影響が出るだろうね。

Hacker Newsで議論の続きを見る