AWSエンジニア、Linux 7.0でPostgreSQL性能が半減したと報告 – 修正は容易でない可能性

 (phoronix.com/news)
7 ポイント 投稿者 GN⁺ 25 일 전 | 2件のコメント | WhatsAppで共有
  • Linux 7.0の開発カーネルで、PostgreSQLデータベースサーバーのスループットが従来カーネル比で約半分に低下する深刻な性能リグレッションがAmazon/AWSエンジニアによって発見された
  • Graviton4サーバーでの測定結果では、Linux 7.0は従来カーネル比で約0.51倍のスループットしか提供せず、その原因はユーザースペースのスピンロックで大幅に多くの時間が消費されることにあると判明した
  • リグレッションの原因は、Linux 7.0で行われたカーネルプリエンプション（preemption）モード制限の変更で、PREEMPT_NONEをデフォルト値として復元するパッチが提出されたものの、採用の見通しは不透明な状況
  • 作者のPeter Zijlstraは、カーネル修正ではなくPostgreSQLがRSEQ（Restartable Sequences）タイムスライス拡張を活用するよう修正すべきだとの立場を示した
  • Linux 7.0安定版は約2週間後にリリース予定で、Ubuntu 26.04 LTSのベースカーネルとしても使われる予定のため、PostgreSQLが適応するまで広範な性能低下が懸念される

問題の発見と規模

  • Amazon/AWSエンジニアのSalvatore DipietroがPostgreSQLのスループットとレイテンシのリグレッションを報告
  • Graviton4サーバー基準の測定で、Linux 7.0は既存カーネル比で0.51倍のスループットしか提供しなかった
    • 原因はユーザースペースのスピンロックで大幅に多くの時間が消費されることだと確認された

リグレッションの原因: プリエンプションモード制限

  • バイセクティング（bisecting）の結果、Linux 7.0でカーネルプリエンプションモードを制限した変更が原因と特定された
  • この変更は最新CPUアーキテクチャを対象にFullおよびLazyプリエンプションモードのみを維持する方向で実施され、Linux 7.0スケジューラ更新の一環として含まれた

提出されたパッチとカーネルメンテナの反応

  • 深刻なリグレッションを理由に、PREEMPT_NONEをデフォルトのプリエンプションモードとして復元するパッチがLinuxカーネルメーリングリストに提出された
  • しかし、元のコードを書いたPeter Zijlstraはこのパッチの受け入れに否定的で、解決策はPostgreSQLがRSEQ（Restartable Sequences）タイムスライス拡張を活用することだと述べている
    • RSEQタイムスライス拡張もLinux 7.0に含まれた機能
    • Zijlstraは「これによりロックホルダーのプリエンプション露出を制限できる」と説明した

影響範囲とリリース日程

  • もしこの立場が維持される場合、PostgreSQLが更新されるまで、Linux 7.0安定版では一部シナリオでPostgreSQL性能が大きく低下する可能性がある
  • Linux 7.0安定版は約2週間後にリリース予定
  • Linux 7.0はUbuntu 26.04 LTSのベースカーネルであり、4月末にリリース予定のUbuntu 26.04 LTSにも同様の影響が及ぶ可能性がある

関連記事

2件のコメント

 
unstabler 25 일 전

聞くところによると、カーネル開発者たちは10〜20年近く前から PostgreSQL 開発者に対して「ユーザーランドでのスピンロックは推奨しないので、見直してほしい」と話していたそうです..

https://x.com/kosaki55tea/status/2040458791536497035
 
GN⁺ 25 일 전
Hacker Newsのコメント

  • Postgres開発者 Andres Freund の LKMLの追補投稿 を読む価値がある

    • 性能問題が 再現可能なリグレッション (regression) であるなら、7.0で新たに追加された機能を無効化しないと解決しないというのは不自然な状況である
    • 単独の投稿ではなく、スレッド全体を追うと 追加情報 が多い
    • 7.0でのみ発生するリグレッションを解決するために、7.0で新たに導入された低レベル機能を強制するのは望ましくない
      Linuxメンテナーは PostgreSQLのような中核アプリ を優先的なサポート対象にすべきだという意見である
      以前 Fedora で Wine をインストールするとアップデートが止まった事例を思い出す
    • 「hugepages を使え」という解決策がいつも提示されるが、ほとんどのユーザーはこれを無視する
    • ARM64 96コアマシンでのみ 性能が0.51倍に低下 し、AMD64では再現されなかった
      つまり、PostgreSQL を最新カーネルへ上げるすべてのユーザーが経験する問題ではない

  • ユーザー空間で spinlock をカーネル支援なしに使うのは、性能低下を自ら招く行為だという意見である

    • 私も Postgres の spinlock 利用は嫌っており、段階的に除去している
      しかし futex ベースのロックは メモリバリアの増加 によって性能リグレッションが生じる
      また Postgres は依然として 8バイトのアトミック演算をサポートしないプラットフォームも考慮しなければならず、置き換えは難しい
      問題の spinlock は最近削除され、huge pages 使用時 にはボトルネックもほぼ消える
    • ユーザー空間で spinlock を使うのは「自分の顔をハンマーで殴るようなものだ」という比喩も出ていた
    • PostgreSQL は古いカーネルとの互換性を維持するために spinlock を使ってきたが、もうやめるべきだという意見もある

  • 「最新カーネルを本番で使う人はいない」という主張もあった
    実際には Ubuntu 26.04 LTS が Linux 7.0ベース でまもなくリリースされるため、多くのユーザーが近く使うことになる
    現時点では sysctl ではなく カーネルパッチ が必要だという点が問題である

    • それでも最新カーネルをテストする人がいなければ、この種の問題を早期に発見できない
    • PostgreSQL が影響を受けるなら、他のアプリケーションも影響を受ける可能性がある
    • Docker 環境ではホストカーネルを共有するため、選択の余地がないという指摘もあった
    • 参考までに PREEMPT_NONE オプションはほとんどのプラットフォームで削除されている

  • PREEMPT_LAZY の背景は LWNの記事 で確認できる

  • 「Jia Tan が最近カーネルパッチを出していないか確認したか」という冗談めいたコメントがあり、
    それに対して「わざわざその必要もない、すでに 脆弱性だらけだ」という返信が付いていた

  • PostgreSQL 18 の 非同期 I/O と並列クエリ最適化 が今回の性能低下を相殺できるのか気になるという意見があった
    関連内容は PostgreSQL 18 リリースノート で確認できる

  • PREEMPT_LAZY のような 動的プリエンプションモード がなぜ必要なのか疑問だという意見もあった
    一般ユーザーが得る利点が不明確だということである

    • これに対する返信として、レイテンシを増やさずにスループットを高めるための設計 だという説明があった
      カーネルがより明示的な情報を受け取り、スケジューリング判断を改善 できるようになるということだ

  • FreeBSD 14 と 15.0 の間で 10%の性能低下 を測定したが、今回の事例を見て慰めになったというコメントがあった

    • 「それでもその分の機能追加はあったのか」という反応が続いた

  • Phoronix が 十分な検証なしに記事化した という批判もあった
    追補メールではベンチマーク自体が誤っており、実際には大きな問題ではないという結論になった

    • ただしリグレッションは huge pages を使わない場合にのみ 発生する
      PostgreSQL には大きな問題ではないかもしれないが、huge pages を使えない他のアプリには影響する可能性がある
      そのため、単純に無視してよい話ではないという意見である

  • 古い LKMLスレッドのリンク も共有されていた