つの接続がクエリを実行しているためです)。負荷だけを表示するのではありません。どのような種類のアクティビティがその負荷の原因となっているかも示します。負荷をグループ化します。負荷の原因であるかを観察することで、パフォーマンスを制限する競合の種類を理解できます。負荷図には重要なグラフィック要素があります。アクティブにできるセッションの最大数を表します。アクティブになります。つのプロセスは実行キューで待機します。ラインは、負荷が使用可能なリソースを超えているかどうか、またはインスタンスに空き容量があるかどうかを測定するための良い基準です。クエリが表示されます。データベースはいつアイドル状態になっているか?データベースがアイドル状態であることを知ることは重要です。データベースがアイドル状態になっていれば、アプリケーションのパフォーマンスの問題は、データベースによるものではない可能性が高くなります。データベースがアイドル状態にあるかどうかを素早く確認できます。データベースの負荷図には何のアクティビティもありません。分の直前にスパイクがあります。前後にピークに達します。サイクルの待機状態にあったことを意味します。アクセスするのに時間の半分近くを費やしていたことになります。倍の速さで動作する可能性があります。負荷グラフの一部を拡大表示できます。負荷スパイクを拡大しています。リストを新しい時間枠に再スコープします。負荷をかける唯一の原因となっています。このシナリオでは、関数の内部ロジックを調べるか、またはアプリケーションが呼び出す頻度を減らすことによって、このストアドプロシージャを最適化することに焦点を当てます。負荷図の左側にスパイクが表示されています。ストレージへの書き込みを待機している状態にあることを示しています。スパイクを拡大すると、次のように表示されます。つの更新ステートメントに由来しています。これらの更新ステートメントを調べると、明示的なトランザクションの一部ではない単一行の更新ステートメントであることがわかります。コミットには耐久性のある書き込みが必要です。したがって、更新後はいつも、安定したストレージへの書き込みを待機しています。ステートメントを最後にコミットするトランザクションにグループ化したりすることができます。ここにマイクロベンチマークの例があります。回の更新を行いました。待機する時間に費やされました。秒しかかかりませんでした。以下の負荷図では、結果を視覚的に見ることができます。して表示されています。負荷の大半が「io/aurora_redo_log_flush」の待機状態であることがわかります。秒のアイドルギャップがあります。秒間のワイドスパイクがあります。倍の速さで、「io/aurora_redo_log_flush」の待機時間がすべて無くなりました。自動コミットをオフにすることによって、コミットはレコードの各バッチの終わりに行うのではなく、すべての更新後に行われるようになり、「io/aurora_redo_log_flush」の待機時間がなくなりました。パフォーマンスのボトルネックを迅速かつ簡単に特定し、そのボトルネックに対処するためのエリアを特定するのに役立ちます。データベース作成時に有効になっています。コンソールで見つかります。すべてのデータの格納、処理、集約は自動的に管理され、データベースホスト外で行われ、データベースへの影響を最小限に抑えます。このブログの投稿に関するコメントは、以下のコメントセクションからお送りください。プロダクトマネージャーです。がい、年齢、その他の属性によって差別することなく、平等に採用選考の機会を提供しています。