MySQL DB インスタンスにおいて、Performance Insights が SYNCH 待機イベントを待っているアクティブなセッション数が多いことを示す原因を知りたいです。

簡単な説明

Performance Insights の MySQL SYNCH 待機イベントは、複数のデータベースセッションが同じ保護オブジェクトまたはメモリ構造にアクセスしている場合に発生します。Amazon Relational Database Service (Amazon RDS) for MySQL、Amazon RDS for MariaDB、Amazon Aurora MySQL 互換エディションでは、次のオブジェクトが保護されています。

• 一度に 1 セッションのみの読み取りまたは書き込みを許可するミューテックスを含む、binlog ソースインスタンス内のアクティブなバイナリログファイル。
• データコントロール言語 (DCL) またはデータ定義言語 (DDL) ステートメントの書き込みに対して保護された、データディクショナリ。
• 一度に 1 セッションのみの読み取りまたは書き込みを許可するミューテックスを含む、適応型ハッシュインデックス。
• 1 セッションのみがキャッシュにテーブルを追加、削除できるオープンテーブルキャッシュ。
• 一度に 1 セッションのみがメモリ内のブロックの内容を変更できる、InnoDB バッファプール内の各データベースブロック。

解決策

DB インスタンスにワークロードを管理するのに十分な CPU リソースがあることを確認する

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

SYNCH イベントは通常長くは続かないため、Amazon CloudWatch メトリクス CPUUtilization にはピーク使用率が正しく表示されない場合があります。このメトリクスの精度は、60 秒のみです。ピーク使用量を確認するには、Amazon RDS コンソールの拡張モニタリングで 1 秒精度のカウンターを使用します。

MySQL ミューテックスを増やすか、待機配列をロックする

MySQL は、内部データ構造を使用して配列サイズがデフォルト値の 1 であるスレッドを調整します。この構成はシングル CPU マシンでは機能しますが、複数の CPU を搭載したマシンでは問題が発生する可能性があります。ワークロードに待機中のスレッドが多数ある場合は、配列サイズを増やしてください。MySQL の innodb_sync_array_size パラメータを、CPU 数と同値以上に変更します。詳細については、MySQL のウェブサイトで innodb_sync_array_size について参照してください。

注: MySQL は、データベースの起動時にのみ innodb_sync_array_size パラメータを使用します。

同時実行を減らす

通常、並列処理を使用するとスループットが向上します。ただし、多数のセッションが同じまたは類似のアクティビティを実行する場合、それらのセッションは同じ保護オブジェクトにアクセスできる必要があります。セッション数が多いほど、待機中の CPU 使用率が増えます。

この問題を解決するには、アクティビティを時間経過に伴い分散させるか、逐次化してスケジュールします。複数行の挿入など、複数の操作を単一のステートメントにまとめることも有効です。

待機イベントに応じて問題をトラブルシューティングする

発生した待機イベントに応じて、次のトラブルシューティング手順を実行します。

synch/rwlock/innodb/dict sys RW lock または synch/rwlock/innodb/dict_operation_lock

これらのイベントは、多数の同時 DCL または DDL が同時に呼び出された場合に発生します。これらの問題をトラブルシューティングするには、通常のアプリケーションアクティビティ中に、アプリケーションの DDL への依存を減らします。

synch/cond/sql/MDL_context::COND_wait_status

このイベントは、DCL または DDL が変更するテーブルに、SELECT を含む多数の SQL がアクセスした場合に発生します。この問題をトラブルシューティングするには、通常のアプリケーションアクティビティ中に、トラフィックの多いテーブルで DDL ステートメントを実行することを避けます。

synch/mutex/sql/LOCK_open または synch/mutex/sql/LOCK_table_cache

これらのイベントは、セッションで開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えると発生します。この問題をトラブルシューティングするには、キャッシュのサイズを増やしてください。詳細については、MySQL のウェブサイトで「10.4.3.1 MySQL でのテーブルのオープンとクローズの方法」を参照してください。

synch/mutex/sql/LOG

このイベントは、現在のログ記録メソッドではサポートできないステートメントが多数、データベースで実行された場合に発生します。出力メソッドに TABLE を使用している場合は、代わりに FILE を使用してください。一般ログを使用する場合は、代わりに Aurora の高度な監査を使用してください。long_query_time パラメータが 0 または 1 未満の値に設定されている場合は、値を増やします。

synch/mutex/innodb/buf_pool_mutex、synch/mutex/innodb/aurora_lock_thread_slot_futex または synch/rwlock/innodb/index_tree_rw_lock

これらのイベントは、類似した多数のデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしたときに発生します。この問題を解決するには、複数行のステートメントとパーティションを使用し、ワークロードを複数のデータベースオブジェクトに分散します。

synch/mutex/innodb/aurora_lock_thread_slot_futex

このイベントは、あるセッションが行を更新対象としてロックしているときに、別のセッションがその行を更新しようとすると発生します。発生した他の待機イベントに応じて、この問題をトラブルシューティングします。この待機イベントの原因となる SQL ステートメントを特定して対処するか、ブロックしているセッションを特定して対処します。

synch/cond/sql/MYSQL_BIN_LOG::COND_done、synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit、またはsynch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

これらのイベントは、バイナリロギングを有効にした際、大量のコミットスループット、コミットトランザクション、またはバイナリログ (binlog) を読み取るレプリカがある場合に発生します。この問題をトラブルシューティングするには、複数行のステートメントを使用するか、複数のステートメントを 1 つのトランザクションにグループ化します。

Aurora MySQL 互換における待機イベントの詳細については、「待機イベントが発生した Aurora MySQL を調整する」および「Aurora MySQL の待機イベント」を参照してください。

データベースを 8.0 以降と互換性のあるメジャーバージョンにアップグレードすることをおすすめします。可能であれば、複数行のステートメントを使用するか、複数のステートメントを 1 つのトランザクションにグループ化します。Aurora では、バイナリログのレプリケーションではなく Aurora Global Database を使用するか、aurora_binlog を使用してください。

関連情報

Amazon RDS で Performance Insights を使用して DB の負荷を監視する

Amazon RDS のパラメータグループ