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

[メモリOOM診断] ビューに表示されるモニタリング項目のトレンドチャートに基づいて、メモリ不足 (OOM) の問題を分析および解決できます。

• メモリ使用量:

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

  • メモリ使用量が突然増加し、InnoDBバッファプールの使用量が変更されない場合、サービスのトラフィックが急増する可能性があります。

  • メモリ使用量とInnoDBバッファプールの使用量の両方が増加すると、InnoDBはアクセスされたままキャッシュされ、期待どおりに動作します。

• レジデントメモリ: メモリ容量を示します。

• Open files、Temp File Size、Temp Disk Tables、Sort Rows: メモリ消費量を表示します。

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

• 业务ログを确认して, メモリ使用量の増加の原因を特定してください。

• メモリ容量を拡張し、SQL Explorerと監査機能を有効にします。 これにより, SQL文が実行された時点で, メモリ使用量の増加の原因を特定できます。 詳細については、「SQLエクスプローラーと監査機能の使用」をご参照ください。

[読み取り専用インスタンス遅延診断] ビューに表示されるモニタリング項目のトレンドチャートに基づいて、読み取り専用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_log_size): ほとんどの場合、クエリの実行時間が長いため、アンドゥログをクリアできません。 長期間実行され、完了していないクエリが存在するかどうかを確認する必要があります。

  説明

  MySQL 5.6以前のバージョンでは、アンドゥログ用に個別のテーブルスペースは用意されていません。

• スロークエリログ (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使用率が変化したときに処理行数が急激に増加するかどうかを確認できます。

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

• 接続関連のモニタリング項目:

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

CPUジッタの一般的な原因:

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

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

[大規模トランザクション認識診断] ビューに表示されるモニタリング項目のトレンドチャートに基づいて、大規模なトランザクション関連の問題を分析および解決できます。

• Threads Connected、Temp File Size、Binlog space: 大きなトランザクションが存在するかどうかを示します。 次のいずれかのイベントが発生した場合、データベースに大きなトランザクションが存在します。

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

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

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

• Rows Processed、Logical Page Write、Queries per Second: 大規模なトランザクションのタイプを示します。

  たとえば、いくつかのクエリが実行されたが、多数の行が削除された場合、データを削除する大きなトランザクションが存在します。

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

• 大規模なトランザクションが存在する場合、一時テーブル (binlogキャッシュ) によって占有されるストレージは徐々に増加し、その後安定したままになります。

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

• RDSインスタンスがRDS High-availability Editionを実行している場合、プライマリ /セカンダリ切り替えのためにプライマリおよびセカンダリRDSインスタンスのステータスを確認するために実行されるステートメントはブロックされます。 その結果、プライマリ /セカンダリの切り替えがRDSインスタンスで直接実行されます。