ApsaraDB RDS:ApsaraDB RDS for MySQL インスタンスのメトリックを表示する

[メモリ OOM 診断] ビューに基づいて、メモリ不足 (OOM) の問題を分析できます。

• [メモリ使用量]：

  • メモリ使用量が 7 日以上など長期間にわたってゆっくりと継続的に増加し、InnoDB バッファープールの使用量が変化しない場合は、メモリリークが発生している可能性があります。

  • メモリ使用量が急激に増加し、InnoDB バッファープールの使用量が変化しない場合は、サービスにトラフィックの急増が発生している可能性があります。

  • メモリ使用量と InnoDB バッファープールの使用量の両方が増加する場合は、InnoDB はアクセス時にキャッシュを行い、想定どおりに動作しています。

• [常駐メモリ]：メモリ容量を表示します。

• [開いているファイル]、[一時ファイルサイズ]、[一時ディスクテーブル]、[ソート行]：メモリ消費量を表示します。

メモリ使用量の増加は、ビジネスメトリックと相関しています。ほとんどの場合、メモリ使用量の増加を引き起こす SQL 文は、OOM エラーのために追跡できません。次の操作を実行することをお勧めします。

• ビジネスログを確認して、メモリ使用量の増加の原因を特定します。

• メモリ容量を拡張し、SQL Explorer および Audit 機能を有効にします。これにより、SQL 文が実行された時点に基づいて、メモリ使用量の増加の原因を特定できます。詳細については、「SQL Explorer および Audit」をご参照ください。

[読み取り専用インスタンスの遅延診断] ビューに基づいて、読み取り専用 RDS インスタンスのレイテンシ関連の問題を分析できます。

• [アクティブセッション]：メタデータロックが存在し、輻輳を引き起こしているかどうかを表示します。

  ほとんどの場合、大量のデータがクエリされると、DDL 文の実行時にメタデータロックを取得できません。その結果、DDL 文は他のセッションをブロックし、接続の蓄積を引き起こします。

• [常駐メモリ]：メモリ容量を表示します。

• [処理された DML 行]、[リクエストされたページ]、[DML/DDL 操作]、[使用済み一時ディスク容量]：一般的なビジネスメトリックを表示します。

• [レプリケーション遅延]：レプリケーションレイテンシを表示します。

ストレージを占有しているファイルの種類と、各ファイルの種類のストレージ使用量のトレンドを確認できます。ほとんどの場合、次の種類のファイルがストレージを占有しています。

• データファイル (user_data_size)：ストレージ分析機能を使用して、各データベースとテーブルのストレージ使用量を確認できます。次に、ビジネス要件に基づいて、ストレージ容量を拡張したり、不要なデータを削除したりできます。ストレージ分析機能の詳細については、「ストレージ分析機能を使用する」をご参照ください。データファイルの処理方法の詳細については、「ApsaraDB RDS for MySQL インスタンスがデータファイルによってストレージ容量を使い果たしたためにロック状態になっている場合の対処方法」をご参照ください。

• 一時ファイル (temp_file_size)：データをソートおよびグループ化したり、テーブルを関連付けたりするために SQL 文を実行すると、一時テーブルが生成される場合があります。バイナリログキャッシュファイルは、ラージトランザクションがコミットされる前に生成されます。これらのテーブルとファイルはストレージを占有します。一時ファイルの処理方法の詳細については、「ApsaraDB RDS for MySQL インスタンスが一時ファイルによってストレージ容量を使い果たしたためにロック状態になっている場合の対処方法」をご参照ください。

• バイナリログ (binlog_size)：バイナリログは、ラージトランザクションによって迅速に生成されます。これらのログはストレージを占有します。バイナリログの処理方法の詳細については、「ApsaraDB RDS for MySQL インスタンスのストレージ容量がバイナリログファイルによって使い果たされた場合の対処方法」をご参照ください。

  説明

  バイナリログがサブスクライブされている場合、バイナリログは早期に削除されず、ストレージを占有する可能性があります。

• UNDO ログ (undo_log_size)：ほとんどの場合、長時間実行されるクエリのために UNDO ログをクリアできません。長時間実行され、完了していないクエリが存在するかどうかを確認する必要があります。

  説明

  MySQL 5.6 以前のバージョンでは、UNDO ログ用に個別の表領域は提供されていません。

• スロークエリログ (slowlog_size)：スロークエリログが大量のストレージを占有している場合は、オフピーク時に TRUNCATE 文を実行してスロークエリログをクリアすることをお勧めします。

  説明

  TRUNCATE 文は、マイナーエンジンバージョン 20210630 以降の MySQL 5.7 およびマイナーエンジンバージョン 20210930 以降の MySQL 8.0 でサポートされています。

• 一般クエリログ (general_log_size): このメトリックの値は、エラーログ、パフォーマンスエージェントログ、およびリカバリログの合計サイズです。ほとんどの場合、これらのログの合計サイズは 1 GB 未満です。サイズが 1 GB を大幅に超える場合は、チケットを送信してください。このメトリックは、MySQL カーネルによって定期的に出力されるカーネルメトリックデータを指定します。MySQL の general_log のログサイズを指定するものではありません。

[CPU ジッター診断] ビューに基づいて、CPU ジッターの問題を分析できます。次の監視項目が提供されています。

• ビジネス監視項目：

  • [ページリクエスト]：ほとんどの場合、バッファープール内のリクエスト数のトレンドは、CPU 使用率に基づいて変動します。

  • [処理された行]：CPU 使用率とシステムによって処理された行数の関係を示します。この監視項目に基づいて、CPU 使用率が変化したときに処理された行数が急激に増加するかどうかを確認できます。

  • [クエリ]：CPU 使用率が変化したときに実行される SQL 文の種類を示します。

• 接続関連の監視項目：

  [実行中のスレッド]：高い同時実行性は、高い CPU 使用率につながります。メタデータロックまたは行ロックは、接続の蓄積を引き起こし、CPU 使用率に影響を与えます。

CPU ジッターの一般的な原因：

• [ページリクエスト] または [処理された行] 監視項目が変化します。この場合、CPU 使用率が変化する期間を選択し、[診断] をクリックして、問題の詳細を取得できます。

• アクティブな接続数が増加します。この場合、ビジネス側から問題を解決する必要があります。

[ラージトランザクション認識診断] ビューに基づいて、ラージトランザクション関連の問題を分析できます。

• [接続されたスレッド]、[一時ファイルサイズ]、[バイナリログ容量]：ラージトランザクションが存在するかどうかを表示します。次のイベントのいずれかが発生した場合、データベースにラージトランザクションが存在します。

  • アクティブセッションが蓄積されます。

  • 一時ファイルによって占有されているストレージが増加し、その後減少します。

  • 一時ファイルによって占有されているストレージは減少しますが、バイナリログによって占有されているストレージは増加します。

• [処理された行]、[論理ページ書き込み]、[1 秒あたりのクエリ数]：ラージトランザクションの種類を表示します。

  たとえば、少数のクエリが実行されたが、多数の行が削除された場合は、データを削除するラージトランザクションが存在します。

ラージトランザクションは、バイナリログの書き込みのブロッキングを引き起こします。

• ラージトランザクションが存在する場合、一時テーブル (バイナリログキャッシュ) によって占有されているストレージは徐々に増加し、その後安定します。

• 一時テーブルによって占有されているストレージが安定すると、バイナリログによって占有されているストレージが増加します。バイナリログは、グローバルにシリアルモードで書き込まれます。その結果、他のトランザクションがブロックされ、接続の蓄積が発生します。

• RDS インスタンスで RDS 高可用性版が実行されている場合、プライマリ/セカンダリスイッチオーバーのためにプライマリ RDS インスタンスとセカンダリ RDS インスタンスのステータスを確認するために実行される文がブロックされます。その結果、RDS インスタンスでプライマリ/セカンダリスイッチオーバーが直接実行されます。