2026.04.09

#28 ES/1 SheltyによるPostgreSQL高負荷の原因可視化事例

ES/1 Shelty
レスポンス
分析事例

目次

開く

     

    はじめに

    今回ご紹介する事例は、PostgreSQL を利用した業務システムで、突発的な高負荷および遅延が不定期で発生し、お客様が「原因が分からず、増強するしかない」とお困りだったケースです。

     

    事象については、CPU・メモリの増強で一時的に回復したものの、“なぜ負荷が高まったのか”という根本原因は不明のままでした。

    この状況を打開したのが、弊社の ES/1 Shelty による客観的データ分析です。


    実際に何が起きていたのかが可視化され、「根拠をもって改善方針を決められる」状態へと大きく前進しました。

    本記事では、ES/1 Sheltyにて、原因分析を行った事例を紹介します。

     

    お客様が抱えていた課題

    事象発生時、お客様は次のような状況にありました。

    • システム全体が遅くなり、最悪の場合はシステム停止してしまう

    • 再起動や増強で一時改善はするが、原因が分からない

    • ログだけでは、どのジョブ・どの設定が影響しているか判断できない

    • 選択肢は「増強」しかなく、いつ再発するか分からない

    このように、障害の原因を特定するための十分な可視化が行われていない状態でした。
    そこで、ES/1 Shelty を導入し、障害の根本原因の特定に取り組みました。

     

    ES/1 Shelty で何を見たのか？

    ES/1 Shelty では、OS のリソース情報やPostgreSQLの内部統計、また、実トランザクションのレスポンス時間を収集・計測し、「いつ、何が起きていたのか」を可視化します。

    今回の分析では、特に以下のデータに着目しました。

     

    ① DBサーバのリソース状況

    まずは OS レベルのリソースから確認しました。
    遅延が発生していた時間帯に、以下のような兆候が見られました。

     

    • CPU使用率が高騰

    • コンテキストスイッチ回数が増加

    • ランキュー長が増加

    • メモリ使用率も高騰


    遅延発生時間帯に CPU効率が低下していたことが見えてきました。

    また、メモリについても高負荷になっていることが確認できました。

     

    ＜ES/1 Sheltyでの確認画面イメージ＞

    （以降の画面イメージはデモ画面のイメージであり、実際のお客様の状況とは異なります。）



    DBサーバのリソース負荷監視
    DBサーバのリソース負荷監視

    ES/1 SheltyでのDBサーバのリソース負荷確認画面

     

    ② PostgreSQL のパフォーマンス状況

    システム遅延（＝レスポンス時間悪化）のタイミングで、DB側のパフォーマンス情報に以下の負荷を確認できました。

    • バックエンド接続数が 200 を超えるタイミングで遅延が発生

    • ロック件数が増加

    • 合計待機数が増加

    • 一時ファイル書き出しも多い

     

    このことから、接続数の増加 → CPU＆メモリ負荷の増大 → ロックや待ちが増加 という流れが読み取れました。


    ＜ES/1 Sheltyでの確認画面イメージ＞

     

    PostgreSQL のパフォーマンス状況1
    PostgreSQL のパフォーマンス状況1

    ES/1 SheltyでのPostgreSQLの負荷監視画面1

     

    PostgreSQL のパフォーマンス状況画面2
    PostgreSQL のパフォーマンス状況画面2

    ES/1 SheltyでのPostgreSQLの負荷監視画面2

     

    ③ 負荷の高い処理の実行

    システム遅延（＝レスポンス時間悪化）のタイミングで、以下の特徴を持つトランザクションが実行されていることが分かりました。

    • 1トランザクションで大量の SQL を実行している

    • しかも 1 件あたりの SQL が重い

    • SELECT範囲が広い

    • JOIN が多い。

     

    こうした処理は ロック保持時間が伸びやすいため、他の処理の遅延にも繋がります。

    ＜ES/1 Sheltyでの確認画面イメージ＞

     
    メソッド、SQL情報
    メソッド、SQL情報

    ES/1 Sheltyでのメソッド、SQL情報確認画面


     

    ES/1 Shelty による分析で見えた“3つの主因”

    ES/1 Shelty のデータと、お客様からいただいた情報を総合すると、以下の3つが負荷増大の主因であることが明確になりました。

     

    ① 接続数（max_connections）の設定値が大きすぎる

    PostgreSQL は「1接続＝1プロセス」のモデルです。
    接続数が増えれば、OS 上でプロセスが増え、CPU の奪い合いが起きます。

    結果として、

    • コンテキストスイッチ増加

    • CPU待ちが発生

    • ロック保持時間が長くなり、ロック競合の増大

     

    結果、さらに他の接続が待たされる…といった負荷の連鎖が発生していました。


    ② work_mem の設定が大きすぎた

    work_mem=40MB が全接続に適用されていました。

    負荷の高いSQLが実行された際に、「1クエリ内のソート回数 × 同時接続数」でメモリ消費が急増したと考えられます。

    メモリ使用状況や、一時ファイル書出しサイズの増加傾向から、ピーク時にメモリ枯渇寸前だったことが判明しました。

     

    ③ DB負荷を押し上げる特定トランザクションの存在

    APサーバ側のアプリケーション情報（メソッド情報）と突き合わせることで

    • 大量の SQL を発行する

    • JOIN が多い

    • テーブル全体スキャンを発生

    といった「重いトランザクション」が見つかりました。

    これがピーク時間帯に走ると、全体のパフォーマンスを押し下げてしまいます。

     

    お客様の変化：「増強するしかない」から「根拠をもって判断できる」へ

    今回の分析を通じて、お客様の状況が大きく変わりました。

    ■ ES/1 Shelty 使用前：

    • 原因不明

    • ハード増強しか選択肢がない

    • いつ再発するか分からない


    ■ ES/1 Shelty 使用後：

    • 原因が数値で明確に

    • 設定変更やジョブ改修の優先度が判断可能に

    • 増強が本当に必要か？どこを直せば効果的か？が判断できるように

     

    つまり、

    「分からないから増強」ではなく、根拠をもって対策を選択できる状態 になりました。


    最終的にご提案した改善内容

    1. 接続数の適正化

    • 検証の結果、1/4 の接続数でも稼働に問題なしと判明。

     

    適正な値で運用することで、リソース競合を防ぐことができるようになりました。

     

    2. work_mem の全体値の見直し

    • グローバル設定は PostgreSQL 推奨値（8MB 程度）に戻す

    • 特定ジョブだけ SET LOCAL work_mem で増やす

     

    無駄なメモリ消費を抑えられます。 

     

    3. 特定ジョブの改善

    • クエリの分割

    • インデックスの追加

    • WHERE 条件の見直し

    • タイムアウト（lock_timeout ）の設定

     

    アプリ・DB双方での改善を提案させていただきました。

     

    おわりに

    今回の事例では、ES/1 Shelty によって “見えない原因” が可視化されたことで、
    お客様が 明確な根拠を持って対策が出来る状態 に変わりました。

    PostgreSQL の高負荷問題は、「CPUが足りない」「メモリが足りない」と見える一方で、
    設定・SQL・接続数の複合要因が潜んでいることが多いものです。

     

    IIMでは、ES/1 Sheltyのツールの提供だけでなく、分析の支援も行っております。

     

    同じようにPostgreSQLの問題分析でお悩みの方の参考になれば幸いです！

     

    執筆者

    Y.I.　

    営業技術本部 カスタマーサクセス統括部 カスタマーサクセス部　

    関連記事