synch/mutex/innodb/trx_sys_mutex - Amazon Aurora

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

synch/mutex/innodb/trx_sys_mutex

Peristiwa synch/mutex/innodb/trx_sys_mutex terjadi ketika terdapat aktivitas basis data tinggi dengan transaksi dalam jumlah besar.

Versi mesin yang relevan

Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:

  • Aurora MySQL versi 2 dan 3

Konteks

Secara internal, mesin basis data InnoDB menggunakan tingkat isolasi baca berulang dengan snapshot untuk menghadirkan konsistensi baca. Hal ini memberi Anda gambaran titik waktu basis data pada saat snapshot dibuat.

Di InnoDB, semua perubahan diterapkan ke basis data segera setelah tersedia, terlepas dari apakah perubahan tersebut di-commit. Pendekatan ini berarti bahwa tanpa kontrol konkurensi multiversi (MVCC), semua pengguna yang terhubung ke basis data akan melihat semua perubahan dan baris terbaru. Karena itu, InnoDB memerlukan cara untuk melacak perubahan guna memahami strategi rollback bila diperlukan.

Untuk melakukannya, InnoDB menggunakan sistem transaksi (trx_sys) untuk melacak snapshot. Sistem transaksi melakukan hal berikut:

  • Melacak ID transaksi untuk setiap baris dalam log pembatalan.

  • Menggunakan struktur InnoDB internal, ReadView, yang membantu mengidentifikasi ID transaksi yang terlihat untuk snapshot.

Kemungkinan penyebab peningkatan peristiwa tunggu

Setiap operasi basis data yang memerlukan penanganan ID transaksi yang konsisten dan terkontrol (membuat, membaca, memperbarui, dan menghapus) akan menghasilkan panggilan dari trx_sys ke mutex.

Panggilan ini terjadi di dalam tiga fungsi:

  • trx_sys_mutex_enter – Menciptakan mutex.

  • trx_sys_mutex_exit – Melepaskan mutex.

  • trx_sys_mutex_own – Menguji apakah mutex dimiliki.

Instrumentasi Skema Performa InnoDB melacak semua panggilan mutex trx_sys. Pelacakan mencakup, tetapi tidak terbatas pada, manajemen trx_sys pada pengaktifan atau penonaktifan basis data, operasi rollback, pembersihan pembatalan, akses baca baris, dan pemuatan pool buffer. Aktivitas basis data yang tinggi dengan transaksi dalam jumlah besar mengakibatkan kemunculan synch/mutex/innodb/trx_sys_mutex di antara peristiwa tunggu teratas.

Untuk informasi selengkapnya, lihat Memantau Peristiwa Tunggu Mutex InnoDB Menggunakan Skema Performa dalam dokumentasi MySQL.

Tindakan

Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.

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 terhadap beban tertinggi. Cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.

Untuk melihat bagan SQL Teratas di AWS Management Console:
  1. 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 bawah bagan Beban basis data, 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 peristiwa tunggu lainnya

Periksa peristiwa tunggu lain yang terkait dengan peristiwa tunggu synch/mutex/innodb/trx_sys_mutex. Dengan melakukannya, Anda dapat memperoleh informasi selengkapnya tentang sifat beban kerja. Sejumlah besar transaksi dapat mengurangi throughput, tetapi beban kerja mungkin juga mengharuskannya.

Untuk informasi selengkapnya tentang cara mengoptimalkan transaksi, lihat Mengoptimalkan Manajemen Transaksi InnoDB dalam dokumentasi MySQL.