io/table/sql/handler - Amazon Aurora:
Versi mesin yang didukungKonteksKemungkinan penyebab peningkatan peristiwa tungguTindakan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

io/table/sql/handler

Peristiwa io/table/sql/handler terjadi ketika pekerjaan telah didelegasikan ke mesin penyimpanan.

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:

  • Aurora SQL Versi saya 3:3.01.0 dan 3.01.1

  • Aurora Versi saya 2 SQL

Konteks

Peristiwa io/table menunjukkan peristiwa tunggu untuk akses ke tabel. Peristiwa ini terjadi terlepas dari apakah data di-cache di pool buffer atau diakses pada disk. Peristiwa io/table/sql/handler menunjukkan peningkatan aktivitas beban kerja.

Handler adalah rutinitas yang berspesialisasi dalam jenis data tertentu atau berfokus pada tugas khusus tertentu. Misalnya, handler peristiwa menerima dan mencerna peristiwa serta sinyal dari sistem operasi atau antarmuka pengguna. Handler memori melakukan tugas-tugas yang berkaitan dengan memori. Handler input file adalah fungsi yang menerima input file dan melakukan tugas khusus pada data, sesuai dengan konteksnya.

Tampilan seperti performance_schema.events_waits_current sering kali menunjukkan io/table/sql/handler ketika peristiwa tunggu sebenarnya adalah peristiwa tunggu bersarang seperti penguncian. Jika peristiwa tunggu sebenarnya bukan io/table/sql/handler, Wawasan Performa akan melaporkan peristiwa tunggu bersarang. Saat melaporkan io/table/sql/handler, Wawasan Performa mewakili pemrosesan InnoDB atas permintaan I/O, bukan peristiwa tunggu bersarang yang tersembunyi. Untuk informasi lebih lanjut, lihat Peristiwa Atom dan Molekul Skema Kinerja di Manual SQL Referensi Saya.

catatan

Namun, di Aurora My SQL versi 3.01.0 dan 3.01.1, dilaporkan sebagai. synch/mutex/innodb/aurora_lock_thread_slot_futex io/table/sql/handler

Peristiwa io/table/sql/handler sering kali muncul dalam peristiwa tunggu teratas dengan peristiwa tunggu I/O seperti io/aurora_redo_log_flush dan io/file/innodb/innodb_data_file.

Kemungkinan penyebab peningkatan peristiwa tunggu

Dalam Wawasan Performa, lonjakan mendadak dalam peristiwa io/table/sql/handler menunjukkan adanya peningkatan aktivitas beban kerja. Peningkatan aktivitas berarti peningkatan I/O.

Performance Insights memfilter peristiwa bersarang IDs dan tidak melaporkan io/table/sql/handler penantian saat peristiwa bersarang yang mendasarinya adalah menunggu kunci. Misalnya, jika peristiwa akar penyebabnya adalah synch/mutex/innodb/aurora_lock_thread_slot_futex, Wawasan Performa akan menampilkan peristiwa tunggu ini dalam peristiwa tunggu teratas, bukan io/table/sql/handler.

Dalam tampilan seperti performance_schema.events_waits_current, peristiwa tunggu untuk io/table/sql/handler sering kali muncul ketika peristiwa tunggu sebenarnya adalah peristiwa tunggu bersarang seperti penguncian. Jika peristiwa tunggu sebenarnya berbeda dengan io/table/sql/handler, Wawasan Performa akan mencari peristiwa tunggu bersarang dan melaporkan peristiwa tunggu sebenarnya, bukan io/table/sql/handler. Saat Wawasan Performa melaporkan io/table/sql/handler, peristiwa tunggu sebenarnya adalah io/table/sql/handler, bukan peristiwa tunggu bersarang yang tersembunyi. Untuk informasi lebih lanjut, lihat Peristiwa Atom dan Molekul Skema Kinerja di Manual Referensi SQL 5.7 Saya.

catatan

Namun, di Aurora My SQL versi 3.01.0 dan 3.01.1, dilaporkan sebagai. synch/mutex/innodb/aurora_lock_thread_slot_futex io/table/sql/handler

Tindakan

Jika peristiwa tunggu ini mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Peristiwa tunggu selalu berada di atas saat basis data aktif. Anda perlu melakukan tindakan hanya bila performa menurun.

Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.

Mengidentifikasi sesi dan kueri penyebab peristiwa

Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.

Untuk menemukan SQL kueri yang bertanggung jawab atas beban tinggi

  1. Masuk ke AWS Management Console dan buka RDS konsol Amazon di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Wawasan Performa.

  3. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.

  4. Dalam bagan Beban basis data, pilih Potong berdasarkan masa tunggu.

  5. Di bagian bawah halaman, pilih Top SQL.

    Bagan mencantumkan SQL kueri yang bertanggung jawab atas pemuatan. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.

Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat posting blog Menganalisis Beban Kerja SQL Saya Amazon Aurora dengan Performance Insights.

Memeriksa korelasi dengan metrik penghitung Wawasan Performa

Periksa metrik penghitung Wawasan Performa seperti Innodb_rows_changed. Jika metrik penghitung berkorelasi dengan io/table/sql/handler, ikuti langkah-langkah berikut:

  1. Dalam Performance Insights, cari SQL laporan yang memperhitungkan peristiwa tunggu io/table/sql/handler teratas. Jika memungkinkan, optimalkan pernyataan ini sehingga mengembalikan lebih sedikit baris.

  2. Ambil tabel teratas dari tampilan schema_table_statistics dan x$schema_table_statistics. Tampilan ini menunjukkan jumlah waktu yang dihabiskan per tabel. Untuk informasi selengkapnya, lihat Tampilan schema_table_statistics dan x$schema_table_statistics di Manual Referensi Saya. SQL

    Secara default, baris diurutkan berdasarkan total waktu tunggu menurun. Tabel dengan pertentangan terbanyak ditampilkan terlebih dahulu. Output menunjukkan apakah waktu dihabiskan untuk membaca, menulis, mengambil, menyisipkan, memperbarui, atau menghapus. Contoh berikut dijalankan pada instance Aurora My SQL 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)

Memeriksa peristiwa tunggu berkorelasi lainnya

Jika synch/sxlock/innodb/btr_search_latch dan io/table/sql/handler bersama-sama berkontribusi paling besar terhadap anomali beban DB, periksa apakah variabel innodb_adaptive_hash_index diaktifkan. Jika ya, coba tingkatkan nilai parameter innodb_adaptive_hash_index_parts.

Jika Adaptive Hash Index dinonaktifkan, coba untuk mengaktifkannya. Untuk mempelajari lebih lanjut tentang Indeks Hash SQL Adaptif Saya, lihat sumber daya berikut:

catatan

Adaptive Hash Index tidak didukung pada instans DB pembaca Aurora.

Dalam kasus tertentu, performa mungkin buruk pada instans pembaca saat synch/sxlock/innodb/btr_search_latch dan io/table/sql/handler bersifat dominan. Jika demikian, coba alihkan beban kerja sementara ke instans DB penulis dan aktifkan Adaptive Hash Index.