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

io/table/sql/handler

io/table/sql/handler イベントは、作業がストレージエンジンに委任されたときに発生します。

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

この待機イベント情報は、以下のエンジンバージョンでサポートされています。

  • Aurora MySQL バージョン 3: 3.01.0 および 3.01.1

  • Aurora MySQL バージョン 2

Context

イベント io/table は、テーブルへのアクセスを待っていることを示します。このイベントは、データがバッファプールにキャッシュされているか、ディスク上でアクセスされているかにかかわらず、発生します。io/table/sql/handler イベントは、ワークロードアクティビティの増加を示します。

ハンドラーは、特定の種類のデータに特化したルーチンか、特定の特別なタスクに焦点を当てたルーチンです。例えば、イベントハンドラーは、オペレーティングシステムまたはユーザーインターフェイスからイベントとシグナルを受信してダイジェストします。メモリハンドラーは、メモリに関連するタスクを実行します。ファイル入力ハンドラは、ファイル入力を受け取り、コンテキストに応じてデータに対して特別なタスクを実行する関数です。

performance_schema.events_waits_current などの ビューは、実際の待機がロックなどのネストされた待機イベントである場合に io/table/sql/handler をよく表示します。実際の待機が io/table/sql/handler ではない場合、Performance Insights はネストされた待機イベントをレポートします。Performance Insights が io/table/sql/handler をレポートする場合、非表示のネストされた待機イベントではなく I/O リクエストの InnoDB 処理を表します。詳細については、MySQL リファレンスマニュアルの「パフォーマンススキーマの原子および分子イベント」を参照してください。

注記

ただし、Aurora MySQL バージョン 3.01.0 および 3.01.1 では、synch/mutex/innodb/aurora_lock_thread_slot_futex は io/table/sql/handler と見なされています。

io/table/sql/handler イベントは多くの場合、io/aurora_redo_log_flush や io/file/innodb/innodb_data_file のような I/O 待機を伴う上位待機イベントに表示されます。

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

Performance Insights で、io/table/sql/handler イベントの急増はワークロードアクティビティの増加を示します。アクティビティの増加は、I/O が増加することを意味します。

Performance Insights はネストイベント ID をフィルタリングし、基盤となるネストされたイベントがロック待機である場合、io/table/sql/handler 待機をレポートします。例えば、根本原因イベントが synch/mutex/innodb/aurora_lock_thread_slot_futex である場合、Performance Insights は io/table/sql/handler ではなく 上位待機イベントにこの待機を表示します。

performance_schema.events_waits_current などのビューは、実際の待機がロックなどのネストされた待機イベントである場合によくio/table/sql/handler の待機を表示します。実際の待ち時間が io/table/sql/handler と異なる場合、Performance Insights はネストされた待機を検索し、io/table/sql/handler の代わりに実際の待機を報告します。Performance Insights が io/table/sql/handler をレポートする場合、実際の待機は非表示のネストされた待機イベントではなく、io/table/sql/handler になります。詳細については、「MySQL 5.7 リファレンスマニュアル」の「パフォーマンススキーマのアトムおよび分子イベント」を参照してください。

注記

ただし、Aurora MySQL バージョン 3.01.0 および 3.01.1 では、synch/mutex/innodb/aurora_lock_thread_slot_futex は io/table/sql/handler と見なされています。

アクション

待機イベントがデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。データベースがアクティブな場合、待機イベントは常に最上位になります。パフォーマンスが低下したときにのみ動作してください。

確認できる他の待機イベントに応じて、異なるアクションをお勧めします。

イベントの原因となるセッションとクエリを特定する

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

高ロードの原因となる 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 を使用したトラブルシューティングの便利な概要については、ブログ記事 Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析 を参照してください。

Performance Insights カウンター指標との相関関係をチェックする

Innodb_rows_changed などの Performance Insights カウンターメトリクスをチェックします。カウンタメトリックが io/table/sql/handler と相関している場合、以下のステップを実行します。

  1. Performance Insights で、io/table/sql/handler トップ待機イベントの原因になっている SQL ステートメントを探します。可能であれば、このステートメントを最適化して、返される行数を減らします。

  2. schema_table_statistics と x$schema_table_statistics ビューからトップテーブルを取得します。これらのビューには、テーブルごとに費やされた時間が表示されます。詳細については、MySQL リファレンスマニュアルの schema_table_statistics と x$schema_table_statistics ビュー を参照してください。

    デフォルトでは、行は合計待機時間の降順でソートされます。競合が最も多いテーブルが初期に表示されます。出力は、読み取り、書き込み、フェッチ、挿入、更新、または削除に時間を費やしているかどうかを示します。次の例は Aurora MySQL 2.09.1 インスタンスで実行されました。

    mysql> select * from sys.schema_table_statistics limit 1\G

*************************** 1. row ***************************
     table_schema: read_only_db
       table_name: sbtest41
    total_latency: 54.11 m
     rows_fetched: 6001557
    fetch_latency: 39.14 m
    rows_inserted: 14833
   insert_latency: 5.78 m
     rows_updated: 30470
   update_latency: 5.39 m
     rows_deleted: 14833
   delete_latency: 3.81 m
 io_read_requests: NULL
          io_read: NULL
  io_read_latency: NULL
io_write_requests: NULL
         io_write: NULL
 io_write_latency: NULL
 io_misc_requests: NULL
  io_misc_latency: NULL
1 row in set (0.11 sec)

他の相関待ちイベントがないかチェックする

synch/sxlock/innodb/btr_search_latch と io/table/sql/handler が共に DB ロードの異常に最も貢献している場合、innodb_adaptive_hash_index 可変がオンになっているかチェックします。もしそうであれば、innodb_adaptive_hash_index_parts パラメータ値を増やすことを検討します。

Adaptive Hash インデックスがオフになっている場合、オンにすることを検討します。MySQL adaptive Hash インデックスの詳細については、以下のリソースを参照してください。

注記

Adaptive Hash インデックスは Aurora Reader DB インスタンスではサポートされていません。

synch/sxlock/innodb/btr_search_latch と io/table/sql/handler が支配的な場合、リーダーインスタンスのパフォーマンスが低下することがあります。その場合は、ワークロードをライター DB インスタンスに一時的にリダイレクトし、Adaptive Hash インデックスをオンにすることを検討してください。