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 MySQL versi 3: 3.01.0 dan 3.01.1

• Aurora MySQL versi 2

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 selengkapnya, lihat Peristiwa Atom dan Molekul Skema Performa dalam Panduan Referensi MySQL.

catatan

Namun, di Aurora MySQL versi 3.01.0 dan 3.01.1, synch/mutex/innodb/aurora_lock_thread_slot_futex dilaporkan sebagai 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.

Wawasan Performa memfilter ID peristiwa bersarang dan tidak melaporkan peristiwa tunggu io/table/sql/handler saat peristiwa bersarang yang mendasarinya adalah peristiwa tunggu penguncian. 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 selengkapnya, lihat Peristiwa Atom dan Molekul Skema Performa dalam Panduan Referensi MySQL 5.7.

catatan

Namun, di Aurora MySQL versi 3.01.0 dan 3.01.1, synch/mutex/innodb/aurora_lock_thread_slot_futex dilaporkan sebagai 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.

Topik

• Mengidentifikasi sesi dan kueri penyebab peristiwa
• Memeriksa korelasi dengan metrik penghitung Wawasan Performa
• Memeriksa peristiwa tunggu berkorelasi lainnya

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 kueri SQL yang bertanggung jawab atas beban tinggi:

1. Masuk ke AWS Management Console, lalu buka konsol Amazon RDS 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 SQL Teratas.

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

Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa.

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 Wawasan Performa, cari pernyataan SQL yang memperhitungkan peristiwa tunggu teratas io/table/sql/handler. 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 dalam Panduan Referensi MySQL.

   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 instans 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)

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 selengkapnya tentang Adaptive Hash Index MySQL, lihat sumber daya berikut:

• Artikel Is Adaptive Hash Index in InnoDB right for my workload? di situs web Percona

• Adaptive Hash Index dalam Panduan Referensi MySQL

• Artikel Contention in MySQL InnoDB: Useful Info From the Semaphores Section di situs web Percona

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.