PostgreSQLの「心臓部」を覗く：Spinlock（スピンロック）との付き合い方
やあ。今日は少しディープな話をしようか。
PostgreSQLを触っていると、たまに「性能が出ない」「特定の処理でCPUが跳ね上がる」なんて壁にぶつかることがあるよね。その原因を深掘りしていくと、必ずと言っていいほど「ロックの待ち行列」という話に行き着く。
でも、世の中の解説記事は「ロックの種類」ばかり並べて、肝心な「どうやってCPUの息遣いを感じるか」という部分が抜け落ちていることが多いんだ。今日は、PostgreSQLの同期制御の最小単位である「スピンロック（Spinlock）」について、現場目線で紐解いていこう。
—
スピンロックって結局何なの？
一言で言えば、「秒速で終わる用事を済ませるための、極めて原始的で強力な手段」だ。
PostgreSQLはマルチプロセスアーキテクチャだから、共有メモリ上のデータ構造を複数のプロセスが同時に触ろうとすると、当然ながらデータが壊れる。そこでロックが必要になるわけだけど、ここで「重いロック（LWLockなど）」を持ち出すまでもない、数命令で終わるような一瞬の処理のために用意されているのがスピンロックなんだ。
なぜ「スピン」なのか
名前の通り、ロックが取れるまで「ひたすら回り続ける（スピンする）」からだよ。
OSに「このプロセスをスリープさせて」と頼むのは、実はかなりのコストがかかる。だから、ほんの数ナノ秒で終わる作業なら、CPUをぶん回してでも、その場でロックを奪い合う方が結果的に速いんだ。
—
現場で意識すべき「CPUのテスト・アンド・セット」
スピンロックの裏側には、CPUが提供するアトミック命令（`TAS: Test-And-Set`）がある。
/ 概念的なスピンロックのループ /
while (TAS(&lock_variable) == 0) {
/ ロックが取れないならループして待ち続ける /
cpu_relax(); / CPUの電力を抑えたり、パイプラインを空ける工夫 /
}
/ — クリティカルセクション — /
/ 終わったらロックを解放 /
S_UNLOCK(&lock_variable);
現場のエンジニアとして覚えておいてほしいのは、「スピンロックの保持時間は極限まで短くあるべき」という鉄則だ。
もし誰かがスピンロックを握ったまま重い処理（ディスクI/Oや複雑な演算）を始めたらどうなると思う？
他のCPUコアが「まだか、まだか」とスピンし続けて、システム全体のCPU使用率が100%に張り付く。いわゆる「スピンロックの競合」というやつだ。PostgreSQLの性能トラブルで一番泣きを見やすいパターンの一つだよ。
—
実践：どういう時に意識すればいい？
普段、SQLを書いている分にはスピンロックを意識する必要はない。でも、以下のケースに踏み込むなら話は別だ。
1. 高並列環境（CPUコア数が多い環境）でのトラブル
- CPUコアが多いほど、スピンロックの奪い合いは激しくなる。PostgreSQLの内部構造（特に共有メモリ周り）へのアクセスが集中すると、この「微細な競合」が無視できないオーバーヘッドになるんだ。
2. 拡張モジュール（C言語）を書くとき
- カスタム関数で共有メモリを操作するなら、スピンロックを使うことになる。ここで絶対にやってはいけないのが、「スピンロック内で`elog(ERROR)`を投げること」だ。ロックを解放せずにエラーで抜けると、そのメモリ領域は永久にデッドロック状態になる。「ロックを取ったら、最短で処理して、必ず解放する」。この緊張感は、C言語でPostgreSQLを拡張する時の醍醐味であり、一番の注意点だ。
—
先輩からのアドバイス
もし君が今、「PostgreSQLの動作が重いし、CPUも高いけど、何が起きているか分からない」という状態なら、`perf`コマンドやPostgreSQLの統計情報（`pg_stat_activity`や`pg_wait_sampling`など）を見てみてほしい。
もし「スピンロック待ち」が異常に長ければ、それは単純なクエリのチューニングでは解決できない領域だ。パラメータの調整や、ハードウェア構成、あるいはアーキテクチャそのものの設計を見直すサインかもしれない。
スピンロックは、PostgreSQLという巨大なエンジンの「心臓の鼓動」のようなものだ。普段は意識しなくていい。でも、一度システムが悲鳴を上げたら、まずはこの「鼓動」が正しく打たれているか、どこで詰まっているのかを想像できるようになってほしい。
そうすれば、君は単なる「データベース利用者」から、「データベースエンジニア」へと一歩近づけるはずだ。
また何か気になったら聞いてくれ。現場からは以上だ。
コメント