PostgreSQLの `max_connections` は、なぜ「とりあえず大きく」してはいけないのか？
PostgreSQLのチューニングを始めると、必ずと言っていいほど最初に突き当たるのが `max_connections` の設定値です。
「コネクションエラーが出たから増やそう」。多くの現場で繰り返されるこの判断ですが、PostgreSQLの内部アーキテクチャを理解しているエンジニアなら、それがどれほど危険な賭けであるかを知っているはずです。今日は、単なる設定値の枠を超えて、メモリ管理とOSのスケジューリングという観点から、このパラメータの「本当の境界線」について深掘りしていきましょう。
—
プロセスモデルの代償：メモリ消費の罠
PostgreSQLは、クライアント1接続ごとに1つのバックエンドプロセスをフォークする「マルチプロセスモデル」を採用しています。これは堅牢性という観点では非常に優れていますが、スケーラビリティにおいては明確なコストを支払うことになります。
`max_connections` を増やすということは、最悪のケース（全コネクションがアクティブな状態）で消費されるメモリ量が増大することを意味します。具体的には、以下の要素が各プロセスごとに積み上がっていきます。
- `work_mem`: ソートやハッシュ操作に使われる領域。これは接続ごとに確保されるため、不用意に大きくすると、接続数×`work_mem` で物理メモリを瞬時に食い潰します。
- バックエンドプロセスのスタックサイズ: 各プロセスがカーネル空間・ユーザー空間で消費するリソース。
- 共有バッファとのバランス: OSのページキャッシュが圧迫されれば、当然ディスクI/Oのレイテンシが悪化します。
「メモリが余っているから大丈夫」というのは甘い考えです。PostgreSQLにおいて、メモリは「キャッシュ」として使われない限り、ただの無駄な在庫なのです。
コンテキストスイッチという見えない敵
`max_connections` を数百、あるいは数千単位に設定した環境で、CPU負荷が急上昇し、クエリの実行速度がガタ落ちした経験はありませんか？
これは多くの場合、コンテキストスイッチのオーバーヘッドが原因です。
CPUの物理コア数に対してアクティブなプロセス数が多すぎると、OSのスケジューラは激しくタスクの切り替えを行います。PostgreSQLのバックエンドプロセスが並列して動くとき、CPUは本来の処理（クエリの実行やプランニング）ではなく、プロセスのコンテキストを保存・復元する作業に貴重なサイクルを費やすことになります。
ある一定の閾値を超えると、コネクションを増やせば増やすほど「スループットが下がる」という、エンジニアにとって最も悲しい逆転現象が発生します。これはOSレベルのスケジューリング限界に達したサインであり、もはやPostgreSQLの設定で解決できる領域ではありません。
トラブルシューティング：私ならこう見る
もし本番環境でパフォーマンスのボトルネックを疑うなら、まずは以下のコマンドやメトリクスに注目します。
1. `vmstat 1` の `cs`（context switches）:
クエリ負荷と比例していない異常な高さを見せているなら、プロセス数が多すぎます。
2. `pg_stat_activity`:
`state` が `idle` であるコネクションがどれだけあるか。もし `idle` が過半数を占めているなら、アプリケーション側のコネクション管理が破綻しています。
3. `log_connections` と `log_disconnections`:
接続と切断が頻繁に繰り返されていないかを確認します。接続のオーバーヘッドを嫌ってコネクションを張りっぱなしにするのと、接続を頻繁に生成するのは、どちらも別の苦痛をサーバーに与えます。
結論：接続数は「絞る」のが定石
結局のところ、`max_connections` を闇雲に増やすのではなく、コネクションプーリングで解決するのが現代のアーキテクチャの正解です。
`PgBouncer` や `pgpool-II` を間に挟むことで、バックエンドのプロセス数を物理的なCPUコア数やメモリ帯域に最適化された値に固定しつつ、アプリケーションからの大量の接続要求を捌く。この「層」を分離する発想こそが、大規模トラフィックを支えるエンジニアの矜持ではないでしょうか。
PostgreSQLは正直なデータベースです。設定値の背後にある「なぜそうなるのか」という理屈を理解してあげれば、期待以上のパフォーマンスで応えてくれます。
設定ファイルをいじる前に、一度 `htop` を開き、プロセスの海を見つめ直してみてください。その数字の裏側に、まだ改善の余地が隠れているはずです。
コメント