Performance Insights で SYNCH 待機イベントを待機しているアクティブセッションの数が多いことが MySQL DB インスタンスに表示されているのはなぜですか?

最終更新日: 2020 年 12 月 14 日

Performance Insights に MySQL SYNCH 待機イベントが表示されている場合は、データベース内の多数のセッションが、同一の保護されたオブジェクトまたはメモリ構造にアクセスしようとしていることを意味します。MySQL で保護されたオブジェクトには、以下が含まれます。

• バイナリログソースインスタンス内のアクティブなバイナリログファイル - 一度に 1 つのセッションだけが読み取りまたは書き込みを許可するミューテックスが含まれています。
• データディクショナリ - 書き込み用。通常、データ制御言語 (DCL) またはデータ定義言語 (DDL) ステートメントによって引き起こされます。
• アダプティブハッシュインデックス - 一度に 1 つのセッションだけが読み書きできるようにするミューテックスが含まれています。
• 開いているテーブルキャッシュ - キャッシュからテーブルを追加または削除できるセッションは 1 つだけです。
• InnoDB バッファプール内の各シングルデータベースブロック - 一度に 1 つのセッションのみがメモリ内のブロックの内容を変更できます。

注: SQL クエリの並列処理を増やすには、いくつかの手順があります。場合によっては、アプリケーションのアーキテクチャと、アプリケーションがこれらの問題を解決するためにデータベースを使用する方法を詳しく調査する必要があります。

SYNCH イベントを待機しているセッションの数が多い場合は、CPU 使用率が高くなります。使用率が 100% に達すると、待機中のセッション数が増加します。トラブルシューティングを行う場合は、DB インスタンスのサイズを大きくして、超過分のワークロードを処理するのに十分な CPU があることを確認します。

通常、これらのイベントは短時間で終了するため、Amazon CloudWatch の CPU 使用率メトリクスには、ピーク使用率が正しく表示されない場合があります。これを確認するための最良の方法は、RDS 拡張モニタリングで 1 秒の CPU カウンターを使用することです。これらのカウンターは、より細かく設定でき、詳細な情報を提供します。

MySQL は、内部データ構造を使用してスレッドを調整します。この配列のサイズは、デフォルトで 1 です。これはシングル CPU のマシンに適していますが、複数の CPU を搭載したマシンでは問題を引き起こす可能性があります。ワークロードに待機中のスレッドが多数ある場合は、配列のサイズを大きくします。MYSQL パラメータ innodb_sync_array_size を CPU の量 (またはそれ以上、最大 1024) に設定します。

注: innodb_sync_array_size パラメータは、データベースの起動時にのみ適用されます。

一般に、並列処理はスループットを向上させるのに役立ちます。しかし、多数のセッションが同一または類似のアクティビティを実行しようとすると、セッションは同一の保護されたオブジェクトにアクセスする必要があります。セッションの数が多いほど、待機中に CPU をより多く使用することになります。

これらのアクティビティが異なる時間帯に実行されるようにしたり、順番に実行されるようにスケジュールを設定したりします。複数行の挿入など、複数の操作を 1 つのステートメントにバンドルすることもできます。

特定の待機イベントをトラブルシューティングするには、以下のサンプルソリューションを使用します。

• synch/rwlock/innodb/dict sys RW lock または synch/rwlock/innodb/dict_operation_lock - これは、DDL の多数の同時 DCL が同時にトリガーされることを示しています。通常のアプリケーションアクティビティ中の DDL の使用に対するアプリケーションの依存関係を減らします。
• synch/cond/sql/MDL_context::COND_wait_status - これは、DCL または DDL が変更しているテーブルにアクセスしようとする SQL (選択を含む) の数が多いことを示しています。通常のアプリケーションアクティビティ中は、トラフィック量の多いテーブルに対して DDL ステートメントを実行しないでください。
• synch/cond/sql/MYSQL_BIN_LOG::COND_done / synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit または synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log - バイナリログを有効にしており、高いコミットスループット、大量のトランザクションのコミット、レプリカによるバイナリログの読み取り、またはこれらの組み合わせが存在している可能性があります。データベースを 5.7 以降と互換性のあるメジャーバージョンにアップグレードすることをご検討ください。また、複数行のステートメントを使用するか、複数のステートメントを 1 つのトランザクションにバンドルします。Aurora では、バイナリログレプリケーションの代わりにグローバルデータベースを使用するか、aurora_binlog_* パラメータを使用します。
• synch/mutex/sql/LOCK_open または synch/mutex/sql/LOCK_table_cache - これは、セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えていることを示しています。これらのキャッシュのサイズを大きくします。
• synch/mutex/sql/LOG - データベースが大量のステートメントを実行している可能性があり、現在のログメソッドを維持できません。TABLE 出力方法を使用している場合は、代わりに FILE の使用を試みてください。一般ログを使用している場合は、代わりに Aurora の高度な監査を使用してください。long_query_time パラメータに 0 または 1 未満を使用する場合は、値の増加を試みてください。
• synch/mutex/innodb/buf_pool_mutex or synch/mutex/innodb/aurora_lock_thread_slot_futex or synch/rwlock/innodb/index_tree_rw_lock - 同じデータベースオブジェクトに同時にアクセスする類似の DML が多数あります。複数行のステートメントの使用を試みてください。また、ワークロードを異なるデータベースオブジェクトに分散してください。これを行う方法の 1 つとして、パーティション化が挙げられます。