今回ご紹介する事例は、PostgreSQL を利用した業務システムで、突発的な高負荷および遅延が不定期で発生し、お客様が「原因が分からず、増強するしかない」とお困りだったケースです。
事象については、CPU・メモリの増強で一時的に回復したものの、“なぜ負荷が高まったのか”という根本原因は不明のままでした。
この状況を打開したのが、弊社の ES/1 Shelty による客観的データ分析です。
実際に何が起きていたのかが可視化され、「根拠をもって改善方針を決められる」状態へと大きく前進しました。
本記事では、ES/1 Sheltyにて、原因分析を行った事例を紹介します。
事象発生時、お客様は次のような状況にありました。
システム全体が遅くなり、最悪の場合はシステム停止してしまう
再起動や増強で一時改善はするが、原因が分からない
ログだけでは、どのジョブ・どの設定が影響しているか判断できない
選択肢は「増強」しかなく、いつ再発するか分からない
このように、障害の原因を特定するための十分な可視化が行われていない状態でした。
そこで、ES/1 Shelty を導入し、障害の根本原因の特定に取り組みました。
ES/1 Shelty では、OS のリソース情報やPostgreSQLの内部統計、また、実トランザクションのレスポンス時間を収集・計測し、「いつ、何が起きていたのか」を可視化します。
今回の分析では、特に以下のデータに着目しました。
まずは OS レベルのリソースから確認しました。
遅延が発生していた時間帯に、以下のような兆候が見られました。
CPU使用率が高騰
コンテキストスイッチ回数が増加
ランキュー長が増加
メモリ使用率も高騰
遅延発生時間帯に CPU効率が低下していたことが見えてきました。
また、メモリについても高負荷になっていることが確認できました。
＜ES/1 Sheltyでの確認画面イメージ＞
（以降の画面イメージはデモ画面のイメージであり、実際のお客様の状況とは異なります。）
システム遅延（＝レスポンス時間悪化）のタイミングで、DB側のパフォーマンス情報に以下の負荷を確認できました。
バックエンド接続数が 200 を超えるタイミングで遅延が発生
ロック件数が増加
合計待機数が増加
一時ファイル書き出しも多い
このことから、接続数の増加 → CPU＆メモリ負荷の増大 → ロックや待ちが増加 という流れが読み取れました。
＜ES/1 Sheltyでの確認画面イメージ＞
システム遅延（＝レスポンス時間悪化）のタイミングで、以下の特徴を持つトランザクションが実行されていることが分かりました。
1トランザクションで大量の SQL を実行している
しかも 1 件あたりの SQL が重い
SELECT範囲が広い
JOIN が多い。
こうした処理は ロック保持時間が伸びやすいため、他の処理の遅延にも繋がります。
＜ES/1 Sheltyでの確認画面イメージ＞
ES/1 Shelty のデータと、お客様からいただいた情報を総合すると、以下の3つが負荷増大の主因であることが明確になりました。
PostgreSQL は「1接続＝1プロセス」のモデルです。
接続数が増えれば、OS 上でプロセスが増え、CPU の奪い合いが起きます。
結果として、
コンテキストスイッチ増加
CPU待ちが発生
ロック保持時間が長くなり、ロック競合の増大
結果、さらに他の接続が待たされる…といった負荷の連鎖が発生していました。
work_mem=40MB が全接続に適用されていました。
負荷の高いSQLが実行された際に、「1クエリ内のソート回数 × 同時接続数」でメモリ消費が急増したと考えられます。
メモリ使用状況や、一時ファイル書出しサイズの増加傾向から、ピーク時にメモリ枯渇寸前だったことが判明しました。
APサーバ側のアプリケーション情報（メソッド情報）と突き合わせることで
大量の SQL を発行する
JOIN が多い
テーブル全体スキャンを発生
といった「重いトランザクション」が見つかりました。
これがピーク時間帯に走ると、全体のパフォーマンスを押し下げてしまいます。
今回の分析を通じて、お客様の状況が大きく変わりました。
■ ES/1 Shelty 使用前：
原因不明
ハード増強しか選択肢がない
いつ再発するか分からない
■ ES/1 Shelty 使用後：
原因が数値で明確に
設定変更やジョブ改修の優先度が判断可能に
増強が本当に必要か？どこを直せば効果的か？が判断できるように
つまり、
「分からないから増強」ではなく、根拠をもって対策を選択できる状態 になりました。
検証の結果、1/4 の接続数でも稼働に問題なしと判明。
適正な値で運用することで、リソース競合を防ぐことができるようになりました。
グローバル設定は PostgreSQL 推奨値（8MB 程度）に戻す
特定ジョブだけ SET LOCAL work_mem で増やす
無駄なメモリ消費を抑えられます。
クエリの分割
インデックスの追加
WHERE 条件の見直し
タイムアウト（lock_timeout ）の設定
アプリ・DB双方での改善を提案させていただきました。
今回の事例では、ES/1 Shelty によって “見えない原因” が可視化されたことで、
お客様が 明確な根拠を持って対策が出来る状態 に変わりました。
PostgreSQL の高負荷問題は、「CPUが足りない」「メモリが足りない」と見える一方で、
設定・SQL・接続数の複合要因が潜んでいることが多いものです。
IIMでは、ES/1 Sheltyのツールの提供だけでなく、分析の支援も行っております。
同じようにPostgreSQLの問題分析でお悩みの方の参考になれば幸いです！