データベース負荷 - Amazon Aurora
アクティブなセッション平均アクティブセッション平均アクティブ実行ディメンション

データベース負荷

データベースロード (DB ロード)は、データベース内のセッションアクティビティのレベルを測定します。毎秒収集されるPerformance Insights のキーメトリクスは DBLoad です。

アクティブなセッション

データベースセッションは、リレーショナルデータベースとのアプリケーションのダイアログを表します。アクティブなセッションとは、DB エンジンに作業を送信し、レスポンスを待っている接続です。

セッションは、CPU での動作中、またはリソースが使用可能になるのを待っているときにアクティブになります。例えば、アクティブなセッションでは、ページ (またはブロック) がメモリに読み込まれるのを待機し、ページからデータを読み取る間に CPU を消費することがあります。

平均アクティブセッション

平均アクティブセッション (AAS)はDBLoadPerformance Insights のメトリクスの単位です。データベース上で同時にアクティブなセッション数を測定します。

毎秒、Performance Insights は、クエリを同時に実行するセッションの数をサンプリングします。Performance Insights は、アクティブなセッションごとに以下のデータを収集します。

  • SQL ステートメント

  • セッション状態 (CPU で実行中または待機中)

  • ホスト

  • SQL を実行しているユーザー

Performance Insights は、特定期間の総セッション数を総サンプル数で割って AAS を計算します。たとえば、次の表は、1 秒間隔で実行中のクエリの連続する 5 つのサンプルを示しています。

例 クエリを実行しているセッション数 AAS 計算
1 2 2 合計 2 セッション/1 サンプル
2 0 1 合計 2 セッション/2 サンプル
3 4 2 合計 6 セッション/3 サンプル
4 0 1.5 合計 6 セッション/4 サンプル
5 4 2 合計 10 セッション/5 サンプル

前述の例では、時間間隔の DB ロードは 2 AAS でした。この測定は、5 つのサンプルを採取した期間に、平均して 2 つのセッションがある時点でアクティブであったことを意味します。

DB ロードの類比は、倉庫内のワーカーアクティビティです。倉庫には100 人のワーカーがいるとします。注文が １ 件入ると、ワーカー １ 人がその注文を処理し、99 人はアイドル状態になります。注文が 100 件入れば、100 人のワーカー全員が同時に注文を処理します。マネージャーが 15 分ごとに同時にアクティブになっているワーカー数を書き留め、その数値をその日の終わりに合計し、その合計をサンプル数で割ると、マネージャーは任意の時点でアクティブなワーカーの平均数を計算します。昨日の平均が 50 人、今日の平均が 75 人だった場合、倉庫の平均アクティビティレベルが上がったことになります。同様に、データベースセッションアクティビティの増加につれて DB ロードが増加します。

平均アクティブ実行

1 秒あたりの平均アクティブ実行 (AAE) は AAS に関連しています。AAE を計算するために、Performance Insightsでは、クエリの合計実行時間を時間間隔で割ります。次の表に、前述の表の同じクエリに対する AAE 計算を示します。

経過時間 (秒) 合計実行時間 (秒) AAE 計算
60 120 2 120 実行秒 / 60 経過秒
120 120 1 120 実行秒 / 120 経過秒
180 380 2.11 380 実行秒 /180秒経過
240 380 (1.58) 380 実行秒/240秒経過
300 600 2 600 実行秒/300 経過秒

ほとんどの場合、クエリの AAS と AAE はほぼ同じです。ただし、計算への入力は異なるデータソースであるため、計算はわずかに異なります。

ディメンション

この db.load メトリクスは、ディメンションと呼ばれるサブコンポーネントに分割できるため、他の時系列メトリクスとは異なります。ディメンションは、DBLoad メトリクスのさまざまな特性のカテゴリにより「スライス化されている」と考えることができます。

パフォーマンスの問題を診断する場合、多くの場合、以下のディメンションが最も役立ちます。

のディメンションの詳細なリストについては、Auroraエンジン、「ディメンションでスライスされた DB の負荷」を参照してください。

待機イベント

待機イベントを指定すると、SQL ステートメントは、特定のイベントが発生するまで待機してから、実行を継続できます。待機イベントは、作業が妨げられる場所を示すため、DB ロードの重要なディメンションまたはカテゴリになります。

すべてのアクティブなセッションはCPU 上で実行されているか、待っています。例えば、セッションがメモリでバッファを検索したり、計算を実行したり、プロシージャコードを実行したりするときに CPU を消費します。セッションが CPU を消費していないときは、メモリバッファが空くのを待っているか、データファイルの読み取りやログの書き込みを待っている可能性があります。セッションのリソース待機時間が長くなると、CPU 上で動作する時間は短くなります。

データベースのチューニングのとき、セッションが待っているリソースを見つけようとすることがよくあります。例えば、2 つまたは 3 つの待機イベントが DBロードの 90% を占めることがあります。これは、平均して、アクティブなセッションが少数のリソースを待機するためにほとんどの時間を費やしていることを意味します。これらの待機の原因がわかれば、解決策を試すことができます。

倉庫ワーカーの例を考えてみましょう。本の注文が入ります。ワーカーは注文を処理するのが遅れる可能性があります。例えば、別のワーカーが現在棚の在庫を補充していたり、台車が利用できなかったりする可能性があります。または、注文ステータスを入力するシステムが遅い可能性があります。ワーカーが待っている時間が長ければ、注文の処理にかかる時間も長くなります。待機は倉庫ワークフローにおいて当たり前のこと分ですが、待機時間があまりにも長くなると生産性が低下します。同様に、セッションの待機が繰り返されたり長時間になると、データベースのパフォーマンスが低下する可能性があります。詳細については、Amazon Aurora ユーザーガイドのAurora PostgreSQL の待機イベントでのチューニングそしてAurora MySQL の待機イベントでのチューニングを参照してください。

待機イベントは、DB エンジンごとに異なります。

上位の SQL

待機イベントはボトルネックを示しますが、上位の SQL は、どのクエリが DB ロードの最も大きな原因になっているかを示します。例えば、多くのクエリが現在データベースで実行されている可能性がありますが、1 つのクエリが DB ロードの 99% を占めている可能性もあります。この場合、負荷が高いと、クエリに問題がある可能性があります。

デフォルトでは、Performance Insights コンソールには、データベース負荷の原因となっている上位の SQL クエリが表示されます。コンソールには、各ステートメントに関連する統計情報も表示されます。特定のステートメントのパフォーマンスの問題を診断するには、その実行プランを調べます。