本文へスキップ

DB connection遅延とConnection Pool

この文書では、代表的なアプリケーション性能障害タイプの一つであるDB連結遅延(DBC遅延)とConnection Poolとの相関関係をモニタリングの観点からご紹介します。

まずダッシュボードのヒットマップウィジェットを通じて一次的に障害状況を認知したと仮定した後分析メニュー下位のヒットマップメニューに移動し、時間を特定する方法で障害状況の前後を見てみましょう。 これをもとにトレース情報とメトリクスチャートなどを通じて障害原因を推論する手順を案内します。

ノート

プレビュー

アプリケーションダッシュボード → ヒットマップ·トランザクション → トレース情報 → メトリクスチャート

  • 問題現象を認知した場合は、過去の記録を照会して障害が発生した時点の前後を照会します。 ヒットマップトランザクションチャートでトランザクション過負荷パターンを確認した後TXトレース一覧により、トランザクション遅延の原因をDB接続の問題として予想できます。

  • 区間別照会後、トレース分析を通じて詳細な実行履歴をステップごとで確認します。 経過時間から最も時間がかかっているのがDBCステップであることが確認できます。

  • メトリクスチャートを通じて様々な指標を一緒に見ていきます。 DB Pool数チャートとDB Active数チャートを比較して、DB Connection Poolの不足が原因であることが特定できます。

  • ユーザーの運用環境に応じてConnection Poolの大きさを徐々に調節したり、リーク防止のために最適化設定をする方法が活用できます。

ヒットマップ異常パターン検出​

ヒットマップ異常パターン検知

障害を認識し、一次的な分析を通じて障害原因を追跡する過程は、迅速さが核心です。 WhaTapは、直観的なビューを提供するだけでなく、根本的な原因を追跡するための追加情報を確保できるよう、過去記録の照会機能も提供します。 アプリケーションダッシュボードのヒットマップウィジェットで例のように急激な異常兆候を感知した場合、次の手順は何でしょうか。

ヒットマップウィジェットで問題区間をドラッグしてトランザクショントレース分析を迅速に進めることもでき、または分析メニュー下位のヒットマップに移動して、時間範囲をより広く特定する方法で前後の状況を確認できます。

ヒットマップTXチャートへ移動 sc

後者の手順で説明します。 ダッシュボードヒットマップウィジェットは、過去10分間に終了したトランザクションのレスポンス時間の分布図です。 つまり、時間範囲を特定して直近10分以上の過去の履歴を確認するには、分析メニュー下位のヒットマップメニューに移動します。 ウィジェット右上の右矢印アイコン矢印アイコンを選択して例のように移動できます。

ヒットマップトランザクションチャート上段の時間セレクタを通じて希望する時間範囲を指定し、過去の記録を照会できます。 異常パターンを確定するため、問題区間前後に広く見てみると、応答が遅れているトランザクションが密集した過負荷パターンを確認できました。

ヒットマップドラグ

このような突然のレスポンス時間の増加とトランザクション過負荷の原因を特定するためにヒットマップトランザクションチャートから問題領域を区間別にドラッグし、トランザクション トレース一覧(TXトレース一覧)を照会してみます。

ヒットマップTX一覧

TXトレース一覧を通じて多数のトランザクションで経過時間対比DB接続時間の占める割合が大きいことが確認できます。 例として/api/system/testURLの場合、総経過時間 25,057msのうちDB接続に24,931msがかかりました。 つまり、一次的にDB接続に問題があると推測できます。 次に、当該トランザクションを選択し、トレース情報ウィンドウで詳細情報を見てみましょう。

ノート

  • ヒットマップの横軸はトランザクション終了時間、縦軸はレスポンス時間を意味します。 ヒットマップで上矢印アイコン矢印アイコンを選択して、縦軸レスポンス時間の遅延区間を80秒まで照会できます。

  • 過負荷パターンのほか、ヒットマップパターン分析の詳細については、次の文書をご参考ください。

トランザクショントレースの分析​

トレース情報ウィンドウでトランザクションの詳細実行履歴をステップごとに確認できます。 このようなトランザクション トレイシングにより、トランザクションの性能低下またはエラーの原因を追跡できます。 トレース分析ウィンドウを照会する時、最初に確認すべき情報は、ステップ別経過時間です。 所要時間を比較することで、性能低下またはエラーの原因を迅速に特定できるからです。

TXトレース分析 sc

該当URLの詳細トレースを見てみましょう。 /api/system/test実行中、PostgreSQL DBに接続して処理するクエリ実行時間は、1msから6msで、比較的大きな問題はありません。 しかし、当該データベース接続待ち時間はそれに比べて確実に長くかかっており、経過時間を一番多くかけているのはDB Connectionステップであることが確認できます。

つまり、この場合、先に予想したとおりDB接続遅延によってトランザクション遅延が発生したことを特定できます。 では、このようなDB接続の遅延を引き起こす原因は何でしょうか。

DB Connection Poolの確認​

DB連結遅延を起こす原因の一つは、Connection Poolの不足です。 Connection Poolのサイズは、同時に処理可能な接続数を意味します。 データベースは、リクエストによるConnectionを生成し、終了するプロセスに多くの時間を使います。 Connection Poolは、事前に一定数のConnectionを生成しておいて、他のリクエストがあるときに現在のConnection Poolを再利用できるようにします。 これを通じて毎回新しいConnectionを作成する必要がないため、応答時間を短縮できます。 問題は、事前に生成しておいたConnection数が、アプリケーションが必要とするConnection数に比べて足りない場合で、この時にDB接続遅延が発生します。

DB Connection Poolの状況を確認するため分析メニューのメトリクスチャートに移動します。 まず、メトリクスチャート左側のリストでデータベースを選択してDBプール数とDBアクティブ数チャートを確認します。

メトリクスチャート

各チャートでも確認できますが、DBプールの最大接続個数は、20個に設定されています。 DBアクティブ数チャートを見ると、20個のプールで継続的な占有が行われていることが確認できます。 事前に設定されたプールを超えるリクエストが入ってくると、DBに余るプールができるまで待機し、これにより遅延が発生します。 CPUおよびメモリ使用量など、リソース状況の照会する際に特異点は見つかりませんでした。 つまり、当該プロジェクトの場合、DB Connectionプールの不足がDBC遅延を引き起こした決定的な原因と予想できます。

では、このようにDB Connection Poolが足りない場合はどうすればいいでしょうか？。 もちろん、解決方法はユーザー環境によって異なる場合があります。 この文書では、その中でConnection Poolサイズ調整とConnection再利用および最適化による事前措置について簡単に案内します。

Connection Poolサイズ調整​

まず、Poolの最大接続数を調整する方法を活用できます。 Poolを徐々に増やしてDBのアクティブ数がプールの最大値内で維持されることを確認し、適切なプール数を設定することです。 しかし、プールの数を過度に大きく指定した場合、リソース消費量の過度な増加により、むしろアプリケーション性能に悪影響を与える恐れがあります。 十分なメモリと処理能力を備えていることを確認した後、運営環境に合わせて調整する必要があります。

Connection再利用および最適化​

2番目にConnection再利用および最適化による方法を活用できます。 例えば、アプリケーションが使用したConnectionを返さないConnection Leakが発生した場合なら、いくらConnection Poolの数を増やしても、遅延の問題を解決できません。 この場合、DBアクティブ数は、右上向グラフが表示されます。 Connection Leakを防ぐためには、使用したConnectionを必ず返却するように管理が必要です。 Connection使用後、明示的に返すように設定したり再利用する方式を適用する方法などがあります。