ApsaraDB RDS:RDS for MySQL メトリクスの表示

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

• [メモリ使用量]:

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

  • InnoDB バッファプールの使用量が変化しないまま、メモリ使用量が突然増加する場合、トラフィックスパイクが原因である可能性があります。

  • メモリと InnoDB バッファプールの使用量が両方とも増加する場合、InnoDB バッファプールが徐々に満たされているため、これは正常です。

• [常駐メモリ]：物理メモリの使用量。

• [オープンファイル]、[一時ファイルサイズ]、[一時ディスクテーブル]、および[ソート行]は、メモリ消費量を示す一般的なメトリックです。

メモリの増加はビジネスメトリクスに関連しています。OOM が原因で、突然のメモリスパイクを引き起こした SQL ステートメントの追跡が困難になることが多いため、次のことを推奨します。

• ビジネスログを確認して、突然のメモリ増加の原因を特定してください。

• メモリ仕様をアップグレードし、SQL Explorer and Audit を有効にしてください。突然のメモリスパイクが発生した場合、SQL クエリの実行時間を確認して原因を特定できます。

[読み取り専用インスタンスの遅延診断] ビューでは、読み取り専用インスタンスの遅延を診断できます。

• [アクティブセッション]: メタデータロックによるブロッキングを確認します。

  通常、大量のデータに対するクエリにより、DDL ステートメントがメタデータロックを取得できなくなります。この場合、DDL ステートメントが他のセッションをブロックし、接続が滞留します。

• [DML 処理行数]、[ページリクエスト数]、[DML/DDL 操作]、および[一時ディスク使用量]: 一般的なビジネスメトリックを表示します。

• [レプリケーション遅延]: レイテンシーメトリック。

インスタンスのストレージ領域を占有するファイルのタイプとその変化傾向を表示できます。次のメトリクスは、ストレージ使用量に一般的に関連しています。

• データファイル (user_data_size)：容量分析を使用して、各データベースとテーブルの領域使用量を表示し、スケールアウトするか不要なデータを削除できます。詳細については、「データファイルによるインスタンスフルの解決策」をご参照ください。

• 一時ファイル (temp_file_size)：データのソートやグループ化、またはテーブルの関連付けを行う SQL ステートメントを実行すると、一時テーブルが生成される場合があります。大規模トランザクションがコミットされる前に、バイナリログキャッシュファイルが生成されます。これらのテーブルとファイルはストレージ領域を占有します。詳細については、「一時ファイルによるインスタンスストレージフルの解決」をご参照ください。

• バイナリログ (binlog_size)：大規模トランザクションは、バイナリログを迅速に生成する可能性があります。これらのログはストレージ領域を占有します。バイナリログの管理方法の詳細については、「MySQL バイナリログファイルによるインスタンスストレージフルの解決」をご参照ください。

  説明

  サービスがデータベースのバイナリログをサブスクライブしている場合、ログが迅速にクリアされず、領域を占有する可能性があります。

• undo ログ (undo_log_size)：ほとんどの場合、長時間実行されるクエリにより、undo ログがクリアされなくなります。完了していない長時間実行されるクエリを確認できます。

  説明

  MySQL 5.6 以前では、undo ログに個別のテーブルスペースはありません。

• スローログ (slowlog_size)：スローログが過剰な領域を使用している場合、オフピーク時に truncate コマンドを使用してクリアできます。

  説明

  truncate コマンドのサポートは、MySQL 5.7 のバージョン 20210630 および MySQL 8.0 のバージョン 20210930 で追加されました。

• 一般ログ (general_log_size)：インスタンスのエラー、Performance Agent、リカバリログの合計サイズで、通常は安定しており 1 GB 未満です。サイズがこの値を 大幅に超える 場合は、 チケットを送信して製品チームにお問い合わせください。このメトリクスは、MySQL カーネルによって定期的に生成されるデータを表しており、MySQL の general_log ファイルのサイズではありません。

[CPU ジッター診断] ビューを使用して CPU ジッターの問題を分析できます。関連メトリックは次のとおりです。

• ビジネスメトリクス：

  • [ページリクエスト]: 通常、バッファープールのリクエストは CPU 使用率と連動して変動します。

  • [処理行数]: CPU 使用率と処理行数の関連性を確認し、処理行数の急増が CPU 使用率の変化に対応しているかどうかを判断します。

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

• 接続：

  [スレッド実行中]: 高コンカレンシーは、高い CPU 使用率を引き起こすことがあります。また、MDL スタッキングや行ロックによって接続が蓄積され、CPU 使用率が増加することもあります。

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

• [ページリクエスト] や [処理済み行数] などのビジネスメトリクスの変更は、CPU 使用率に影響を与える可能性があります。このような場合、CPU 使用率が変化した時間範囲を選択し、[診断] を実行して詳細な根本原因分析を取得できます。

• アクティブな接続の増加により CPU が消費されます。この場合、ビジネス側から問題を調査する必要があります。

[大規模トランザクション特定診断] ビューを使用して、大規模トランザクションの問題を分析できます。

• [接続中のスレッド]、[一時ファイルサイズ]、および [Binlog スペース] は、大規模トランザクションを示す 3 つの主要な指標です。 以下のいずれかのイベントが発生した場合、データベースに大規模トランザクションが存在します。

  • アクティブセッションが滞留する。

  • 一時領域がまず増加し、その後減少する。

  • 一時領域が減少した後、バイナリログ領域が増加する。

• [処理済み行数]、[論理ページ書き込み]、[秒間クエリ数]：これらのメトリックは、大規模なトランザクションのタイプを判断するために使用されます。

  たとえば、クエリが少ないが多くの行が削除されている場合、データを削除する大規模トランザクションであることを示します。

大規模トランザクションはバイナリログの書き込みをブロックする可能性があります。

• インスタンスに大規模トランザクションがある場合、一時テーブルスペース (バイナリログキャッシュ) が最初に徐々に増加し、その後安定します。

• 一時テーブルスペースが安定すると、バイナリログ領域が増加します。バイナリログの書き込みはグローバルに直列処理されるため、他のトランザクションがブロックされ、接続が滞留します。

• インスタンスが RDS High-availability Edition を実行している場合、プライマリインスタンスとセカンダリインスタンスの HA コンポーネントからのプローブステートメントもブロックされ、プライマリ/セカンダリフェイルオーバーが発生します。