synch/rwlock/innodb/hash_table_locks - Amazon Aurora
サポート対象エンジンバージョンContext待ち時間増加の考えられる原因アクション

synch/rwlock/innodb/hash_table_locks

synch/rwlock/innodb/hash_table_locks イベントは、バッファキャッシュをマッピングするハッシュテーブルの変更に競合がある場合に発生します。

サポート対象エンジンバージョン

この待機イベント情報は、Aurora MySQL バージョン 1 から 1.23.1 でサポートされています。

Context

イベント synch/rwlock/innodb/hash_table_locks は、バッファキャッシュをマッピングするハッシュテーブルの変更に競合がある場合に発生します。ハッシュテーブルは、バッファプールアクセスのパフォーマンスを向上させるために設計されたメモリ内のテーブルです。この待機イベントは、ハッシュテーブルを変更する必要があるときに呼び出されます。

詳細については、MySQL ドキュメントのバッファプールを参照してください。

待ち時間増加の考えられる原因

synch/rwlock/innodb/hash_table_locks イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。

サイズの小さいバッファープール

バッファプールのサイズが小さすぎて、頻繁にアクセスされるすべてのページをメモリ内に保持できません。

ヘビーワークロード

ワークロードによって、バッファキャッシュで頻繁にエビクションとデータページがリロードされます。

アクション

待機イベントの原因に応じたさまざまなアクションをお勧めします。

バッファプールのサイズを増やす

バッファプールがワークロードに合わせて適切なサイズになっていることを確認します。そのためには、バッファプールのキャッシュヒット率を確認できます。通常、値が 95% を下回った場合は、バッファプールのサイズを大きくすることを検討してください。バッファプールが大きいほど、頻繁にアクセスされるページをメモリ内に長く保持できます。

バッファプールのサイズを増やすには、innodb_buffer_pool_size パラメータの値を変更します。このパラメータのデフォルト値は、DB インスタンスクラスのサイズに基づいています。詳細については、AWS データベースブログ記事の Amazon RDS for MySQL のパラメータを構成するためのベストプラクティス、パート 1: パフォーマンスに関するパラメータ を参照してください。

データアクセスパターンの改善

この待機の影響を受けるクエリとその実行プランを確認します。データアクセスパターンの改善を検討してください。例えばmysqli_result። fetch_array を使用している場合には、配列のフェッチサイズを大きくしてみるなどが可能です。

Performance Insights を使用して、synch/rwlock/innodb/hash_table_locks 待機イベントの原因となっている可能性のあるクエリとセッションを表示できます。

高ロードの原因となる SQL クエリを検索する

通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。

高ロードの原因となる SQL クエリを検索するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Performance Insights] を選択します。

  3. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。

  4. データベースロードで、待機でスライスを選択します。

  5. ページの下部で トップ SQL を選択します。

    グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。

Performance Insights を使用したトラブルシューティングの便利な概要については、AWS　データベースブログ記事の Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析を参照してください。

フルテーブルスキャンの削減または回避

ワークロードをモニタリングして、フルテーブルスキャンが実行されているかどうかを確認し、実行している場合はそれを減らすか回避します。例えば、Handler_read_rnd_next のようなステータス可変をモニタリングできます。詳細については、MySQL ドキュメントのサーバーステータス可変を参照してください。