synch/mutex/innodb/buf_pool_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/buf_pool_mutex

Peristiwa synch/mutex/innodb/buf_pool_mutex terjadi saat thread telah mendapat kunci pada kumpulan buffer InnoDB untuk mengakses halaman dalam memori.

Versi mesin yang relevan

Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:

  • Aurora MySQL versi 2

Konteks

Mutex buf_pool adalah mutex tunggal yang melindungi struktur data kontrol dari pool buffer.

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

Kemungkinan penyebab peningkatan peristiwa tunggu

Ini adalah peristiwa tunggu khusus beban kerja. Penyebab umum synch/mutex/innodb/buf_pool_mutex muncul di antara peristiwa tunggu teratas mencakup yang berikut:

  • Ukuran pool buffer tidak cukup besar untuk menampung set data kerja.

  • Beban kerja lebih spesifik untuk halaman tertentu dari tabel tertentu dalam basis data, yang mengarah ke pertentangan dalam pool buffer.

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

Untuk melihat bagan SQL Teratas di Konsol Manajemen AWS:
  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.

Menggunakan Wawasan Performa

Peristiwa ini terkait dengan beban kerja. Anda dapat menggunakan Wawasan Performa untuk melakukan hal berikut:

  • Mengidentifikasi kapan peristiwa tunggu dimulai dan apakah ada perubahan beban kerja pada saat itu dari log aplikasi atau sumber terkait.

  • Mengidentifikasi pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini. Periksa rencana eksekusi kueri untuk memastikan bahwa kueri ini dioptimalkan dan menggunakan indeks yang sesuai.

    Jika kueri teratas yang bertanggung jawab atas peristiwa tunggu berkaitan dengan objek atau tabel basis data yang sama, coba buat partisi untuk objek atau tabel tersebut.

Membuat Aurora Replicas

Anda dapat membuat Aurora Replicas untuk menyajikan lalu lintas hanya-baca. Anda juga dapat menggunakan Aurora Auto Scaling untuk menangani lonjakan lalu lintas baca. Pastikan untuk menjalankan tugas hanya-baca terjadwal dan pencadangan logis pada Aurora Replicas.

Untuk informasi selengkapnya, lihat Auto Scaling Amazon Aurora dengan Replika Aurora.

Memeriksa ukuran pool buffer

Periksa apakah ukuran pool buffer cukup untuk beban kerja dengan melihat metrik innodb_buffer_pool_wait_free. Jika nilai metrik ini tinggi dan terus bertambah, berarti ukuran pool buffer tidak cukup untuk menangani beban kerja. Jika innodb_buffer_pool_size telah diatur dengan benar, nilai innodb_buffer_pool_wait_free pasti kecil. Untuk informasi selengkapnya, lihat Innodb_buffer_pool_wait_free dalam dokumentasi MySQL.

Tingkatkan ukuran pool buffer jika instans DB memiliki cukup memori untuk buffer sesi dan tugas sistem operasi. Jika tidak, ubah instans DB ke kelas instans DB yang lebih besar untuk memperoleh memori tambahan yang dapat dialokasikan ke pool buffer.

catatan

Aurora MySQL secara otomatis menyesuaikan nilai innodb_buffer_pool_instances berdasarkan innodb_buffer_pool_size yang dikonfigurasi.

Memantau riwayat status global

Dengan memantau tingkat perubahan variabel status, Anda dapat mendeteksi masalah penguncian atau memori pada instans DB Anda. Aktifkan Global Status History (GoSH) jika belum diaktifkan. Untuk informasi selengkapnya tentang GoSH, lihat Mengelola riwayat status global.

Anda juga dapat membuat metrik Amazon CloudWatch kustom untuk memantau variabel status. Untuk informasi selengkapnya, lihat Memublikasikan metrik kustom.