Linux 7.0でPostgreSQL性能が50%ダウン!? スケジューラ変更の罠

📰 ニュース概要

• 性能の劇的低下: Linux 7.0を搭載した96-vCPUのGraviton4マシンで、PostgreSQLのスループットがLinux 6.xと比較して約半分（約9.8万件→約5万件/秒）に低下した。
• ボトルネックの特定: AWSのエンジニアSalvatore Dipietro氏の調査により、CPU時間の55%以上がs_lock（スピンロック）関数で消費されていることが判明。
• スケジューラの仕様変更: Linux 7.0で従来推奨されていたサーバー向け設定「PREEMPT_NONE」が廃止され、強制的に「PREEMPT_LAZY」や「FULL」が適用されるようになったことが原因。

💡 重要なポイント

• スピンロックの崩壊: スピンロックを保持しているスレッドが、カーネルによって実行を中断（プリエンプション）されることで、他のスレッドがそのロックを待って空転し続ける「負の連鎖」が発生している。
• StrategyGetBufferの競合: PostgreSQLが共有バッファプールからバッファを探す際に使用するStrategyGetBuffer関数での競合が致命的なダメージを与えている。
• モダンアーキテクチャの課題: 多コア環境（96 vCPU）かつ高並列負荷という極限状態において、OSのスケジューリングの微差がシステム全体を麻痺させるリスクが浮き彫りになった。

🦈 サメの眼（キュレーターの視点）

このニュースは、OSの「良かれと思った進化」がデータベースのようなミドルウェアの心臓部を直撃した非常に興味深い事例だサメ！

特に、Linux 6.12で妥協案として導入されたはずの「PREEMPT_LAZY」が、PostgreSQLのようなスピンロックを多用する高負荷サーバーワークロードでは不十分だったという点が極めて具体的だサメ。55%ものCPU時間がたった一つの関数s_lockで溶けている事実は、OSのプリエンプション（割り込み）がいかに精密なバランスの上に成り立っているかを物語っているサメ。Linux 7.0という最新環境への移行を考えているエンジニアは、この「スケジューラの罠」を避けるためのパッチ適用や設定変更が必須になるはずだサメ！

🚀 これからどうなる？

Linuxカーネルコミュニティにおいて、今回のPostgreSQLのようなケースを救済するためのプリエンプション制御パッチが議論され、修正が導入される可能性が高い。また、データベース側でもスピンロックに頼りすぎない、より高度なロックフリーアルゴリズムへの移行が加速するかもしれないサメ。

💬 はるサメ視点の一言

最新OSが必ずしも速いとは限らないサメ！スピンロックで目が回って、サメもバターになりそうだサメ〜！🦈🌀

📚 用語解説

• プリエンプション: 実行中のプロセスをOSが強制的に中断し、別のプロセスにCPUを割り当てること。

• スピンロック: ロックが解放されるまで、CPUがループ（空転）して待ち続ける軽量な同期機構。

• バッファプール: データベースがディスクから読み込んだデータをメモリ上にキャッシュしておくための領域。

• 情報元: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained