# データベース負荷 *データベース負荷 (DB 負荷)* は、データベース内のセッションアクティビティのレベルを測定します。`DBLoad` は Performance Insights の主要なメトリクスで、Performance Insights は 1 秒ごとに DB 負荷を収集します。 **Topics** + [アクティブなセッション](#USER_PerfInsights.Overview.ActiveSessions.active-sessions) + [平均アクティブセッション](#USER_PerfInsights.Overview.ActiveSessions.AAS) + [平均アクティブ実行](#USER_PerfInsights.Overview.ActiveSessions.AAE) + [ディメンション](#USER_PerfInsights.Overview.ActiveSessions.dimensions) ## アクティブなセッション *データベースセッション*は、リレーショナルデータベースとのアプリケーションのダイアログを表します。アクティブなセッションとは、DB エンジンに作業を送信し、レスポンスを待っている接続です。 セッションは、CPU での動作中、またはリソースが使用可能になるのを待っているときにアクティブになります。例えば、アクティブなセッションでは、ページ (またはブロック) がメモリに読み込まれるのを待機し、ページからデータを読み取る間に CPU を消費することがあります。 ## 平均アクティブセッション *平均アクティブセッション (AAS)*は`DBLoad`Performance Insights のメトリクスの単位です。データベース上で同時にアクティブなセッション数を測定します。 毎秒、Performance Insights は、クエリを同時に実行するセッションの数をサンプリングします。Performance Insights は、アクティブなセッションごとに以下のデータを収集します。 + SQL ステートメント + セッション状態 (CPU で実行中または待機中) + ホスト + SQL を実行しているユーザー Performance Insights は、特定期間の総セッション数を総サンプル数で割って AAS を計算します。たとえば、次の表は、1 秒間隔で実行中のクエリの連続する 5 つのサンプルを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html) 前述の例では、時間間隔の DB ロードは 2 AAS でした。この測定は、5 つのサンプルを採取した期間に、平均して 2 つのセッションがある時点でアクティブであったことを意味します。 ## 平均アクティブ実行 1 秒あたりの平均アクティブ実行 (AAE) は AAS に関連しています。AAE を計算するために、Performance Insightsでは、クエリの合計実行時間を時間間隔で割ります。次の表に、前述の表の同じクエリに対する AAE 計算を示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html) ほとんどの場合、クエリの AAS と AAE はほぼ同じです。ただし、計算への入力は異なるデータソースであるため、計算はわずかに異なります。 ## ディメンション この `db.load` メトリクスは、ディメンションと呼ばれるサブコンポーネントに分割できるため、他の時系列メトリクスとは異なります。ディメンションは、`DBLoad` メトリクスのさまざまな特性のカテゴリにより「スライス化されている」と考えることができます。 パフォーマンスの問題を診断する場合、多くの場合、以下のディメンションが最も役立ちます。 **Topics** + [待機イベント](#USER_PerfInsights.Overview.ActiveSessions.waits) + [上位の SQL](#USER_PerfInsights.Overview.ActiveSessions.top-sql) のディメンションの詳細なリストについては、Auroraエンジン、「[ディメンションでスライスされた DB の負荷](USER_PerfInsights.UsingDashboard.Components.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims)」を参照してください。 ### 待機イベント *待機イベント*を指定すると、SQL ステートメントは、特定のイベントが発生するまで待機してから、実行を継続できます。待機イベントは、作業が妨げられる場所を示すため、DB ロードの重要なディメンションまたはカテゴリになります。 すべてのアクティブなセッションはCPU 上で実行されているか、待っています。例えば、セッションがメモリでバッファを検索したり、計算を実行したり、プロシージャコードを実行したりするときに CPU を消費します。セッションが CPU を消費していないときは、メモリバッファが空くのを待っているか、データファイルの読み取りやログの書き込みを待っている可能性があります。セッションのリソース待機時間が長くなると、CPU 上で動作する時間は短くなります。 データベースのチューニングのとき、セッションが待っているリソースを見つけようとすることがよくあります。例えば、2 つまたは 3 つの待機イベントが DBロードの 90% を占めることがあります。これは、平均して、アクティブなセッションが少数のリソースを待機するためにほとんどの時間を費やしていることを意味します。これらの待機の原因がわかれば、解決策を試すことができます。 待機イベントは、DB エンジンごとに異なります。 + Aurora MySQL の代表的な待機イベントのリストについては、「[Aurora MySQL の待機イベント](AuroraMySQL.Reference.Waitevents.md)」を参照してください。これらの待機イベントを使用したチューニング方法については、「[Aurora MySQL のチューニング](AuroraMySQL.Managing.Tuning.md)」を参照してください。 + MySQL のすべての待機イベントの詳細については、MySQL ドキュメントの「[イベント待機サマリーテーブル](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html)」を参照してください。 + Aurora PostgreSQL の代表的な待機イベントのリストについては、「[Amazon Aurora PostgreSQL のイベント](AuroraPostgreSQL.Reference.Waitevents.md)」を参照してください。これらの待機イベントを使用して調整する方法については、「[Aurora PostgreSQL の待機イベントでのチューニング](AuroraPostgreSQL.Tuning.md)」を参照してください。 + すべての PostgreSQL 待機イベントの詳細については、PostgreSQL ドキュメントの「[統計コレクター > 待機イベントテーブル](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE)」を参照してください。 ### 上位の SQL 待機イベントはボトルネックを示しますが、上位の SQL は、どのクエリが DB ロードの最も大きな原因になっているかを示します。例えば、多くのクエリが現在データベースで実行されている可能性がありますが、1 つのクエリが DB ロードの 99% を占めている可能性もあります。この場合、負荷が高いと、クエリに問題がある可能性があります。 デフォルトでは、Performance Insights コンソールには、データベース負荷の原因となっている上位の SQL クエリが表示されます。コンソールには、各ステートメントに関連する統計情報も表示されます。特定のステートメントのパフォーマンスの問題を診断するには、その実行プランを調べます。