synch/sxlock/innodb/hash_table_locks
synch/sxlock/innodb/hash_table_locks イベントは、バッファプール内に見つからないページをストレージから読み込む必要があるときに発生します。
サポート対象エンジンバージョン
この待機イベント情報は、以下のバージョンでサポートされています:
-
Aurora MySQL バージョン 2 および 3
Context
イベント synch/sxlock/innodb/hash_table_locks は、ワークロードがバッファプールに保存されていないデータに頻繁にアクセスしていることを示します。この待機イベントは、バッファプールからの新しいページの追加と古いデータの削除に関連付けられます。バッファプールに格納されたデータは、古いデータおよび新しいデータをキャッシュする必要があります。そのため、古いページは削除され、新しいページのキャッシュが可能になります。MySQL は、バッファプールからページを削除するために、最近一番使用されていない (LRU) アルゴリズムを使用します。ワークロードは、バッファプールにロードされていないデータ、またはバッファプールから削除されたデータにアクセスしようとしています。
この待機イベントは、ワークロードがディスク上のファイル内のデータにアクセスする必要がある場合、またはブロックがバッファプールの LRU リストから解放または追加されたときに発生します。これらのオペレーションは、共有除外ロック (SX-Lock) の取得を待ちます。この SX-Lock は、ハッシュテーブル上での同期化に使われます。これは、バッファプールのアクセスパフォーマンスを向上させるために設計されたメモリ内のテーブルです。
詳細については、MySQL ドキュメントのバッファプール
待ち時間増加の考えられる原因
synch/sxlock/innodb/hash_table_locks 待機イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
- サイズの小さいバッファープール
-
バッファプールのサイズが小さすぎて、頻繁にアクセスされるすべてのページをメモリ内に保持できません。
- ヘビーワークロード
-
ワークロードによって、バッファキャッシュで頻繁にエビクションとデータページがリロードされます。
- ページの読み取り中にエラーが発生しました
-
バッファープール内のページの読み取り中にエラーが発生しました。これは、データの破損を示している可能性があります。
アクション
待機イベントの原因に応じて、異なるアクションをお勧めします。
バッファプールのサイズを増やす
バッファプールがワークロードに合わせて適切なサイズになっていることを確認します。そのためには、バッファプールのキャッシュヒット率を確認できます。通常、値が 95% を下回った場合は、バッファプールのサイズを大きくすることを検討してください。バッファプールが大きいほど、頻繁にアクセスされるページをメモリ内に長く保持できます。バッファプールのサイズを増やすには、innodb_buffer_pool_size パラメータの値を変更します。このパラメータのデフォルト値は、DB インスタンスクラスのサイズに基づいています。詳細については、Amazon Aurora MySQL データベース設定のベストプラクティス
データアクセスパターンの改善
この待機の影響を受けるクエリとその実行プランを確認します。データアクセスパターンの改善を検討してください。例えばmysqli_result:: fetch_array
Performance Insights を使用して、synch/sxlock/innodb/hash_table_locks 待機イベントの原因となっている可能性のあるクエリとセッションを表示できます。
高ロードの原因となる SQL クエリを検索するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、[Performance Insights] を選択します。
-
DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
-
データベースロードで、待機でスライスを選択します。
-
ページの下部で トップ SQL を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、AWS データベースブログ記事の Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析
フルテーブルスキャンの削減または回避
ワークロードをモニタリングして、フルテーブルスキャンが実行されているかどうかを確認し、実行している場合はそれを減らすか回避します。例えば、Handler_read_rnd_next のようなステータス可変をモニタリングできます。詳細については、MySQL ドキュメントのサーバーステータス可変
エラーログでページの破損を確認します。
mysql-error.log をチェックして、問題の発生時に検出された破損関連のメッセージを確認できます。問題を解決するために作業できるメッセージは、エラーログに記録されます。破損として報告されたオブジェクトを再作成する必要がある場合があります。
