synch/mutex/innodb/temp_pool_manager_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/temp_pool_manager_mutex

Peristiwa synch/mutex/innodb/temp_pool_manager_mutex tunggu terjadi ketika sesi menunggu untuk memperoleh mutex untuk mengelola kumpulan ruang tabel sementara sesi.

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:

  • Aurora MySQL versi 3

Konteks

Aurora MySQL versi 3.x dan yang lebih tinggi digunakan temp_pool_manager_mutex untuk mengontrol beberapa sesi mengakses kolam tablespace sementara pada saat yang bersamaan. Aurora MySQL mengelola penyimpanan melalui volume cluster Aurora untuk data persisten dan penyimpanan lokal untuk file sementara. Sebuah tablespace sementara diperlukan ketika sesi membuat tabel sementara pada volume cluster Aurora.

Saat sesi pertama kali meminta tablespace sementara, MySQL mengalokasikan ruang tabel sementara sesi dari kolam bersama. Sesi dapat menampung hingga 2 ruang tabel sementara sekaligus untuk jenis tabel berikut:

  • Tabel sementara yang dibuat pengguna

  • Tabel sementara internal yang dihasilkan pengoptimal

TempTableMesin default menggunakan mekanisme overflow berikut untuk menangani tabel sementara:

  • Menyimpan tabel dalam RAM hingga temptable_max_rambatasnya.

  • Pindah ke file yang dipetakan memori di penyimpanan lokal saat RAM penuh.

  • Menggunakan volume cluster bersama saat file yang dipetakan memori mencapai batasnya. temptable_max_mmap

Setelah tabel sementara melebihi RAM dan batas penyimpanan lokal, MySQL mengelolanya menggunakan tablespace on-disk.

Ketika sesi membutuhkan tabel sementara pada disk, MySQL:

  • Mencari INACTIVE ruang meja yang tersedia di kolam untuk digunakan kembali.

  • Membuat 10 ruang tabel baru jika tidak ada INACTIVE spasi.

Ketika sesi terputus, MySQL:

  • Memangkas ruang tabel sementara sesi.

  • Tandai mereka sebagai TIDAK AKTIF di kolam untuk digunakan kembali.

  • Mempertahankan ukuran pool saat ini sampai server restart.

  • Kembali ke ukuran kolam default (10 tablespaces) setelah restart.

Kemungkinan penyebab peningkatan peristiwa tunggu

Situasi umum yang menyebabkan acara tunggu ini:

  • Sesi bersamaan membuat tabel sementara internal pada volume cluster.

  • Sesi bersamaan membuat tabel sementara pengguna pada volume cluster.

  • Penghentian sesi secara tiba-tiba menggunakan ruang tabel aktif.

  • Ekspansi kolam tablespace selama beban kerja tulis berat.

  • Kueri bersamaan mengakses INFORMATION_SCHEMA.

Tindakan

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

Pantau dan optimalkan penggunaan tabel sementara

Untuk memantau dan mengoptimalkan penggunaan tabel sementara, gunakan salah satu metode berikut:

  • Periksa Created_tmp_disk_tables penghitung di Performance Insights untuk melacak pembuatan tabel sementara di disk di seluruh klaster Aurora Anda.

  • Jalankan perintah ini di database Anda untuk secara langsung memonitor pembuatan tabel sementara:mysql> show status like '%created_tmp_disk%'.

catatan

Perilaku tabel sementara berbeda antara node pembaca MySQL Aurora dan node penulis. Untuk informasi selengkapnya, lihat Perilaku tabel sementara baru di Aurora MySQL versi 3.

Setelah mengidentifikasi kueri yang membuat tabel sementara, lakukan langkah-langkah pengoptimalan ini:

  • Gunakan EXPLAIN untuk memeriksa rencana eksekusi kueri dan mengidentifikasi di mana dan mengapa tabel sementara sedang dibuat.

  • Ubah kueri untuk mengurangi penggunaan tabel sementara jika memungkinkan.

Jika optimasi kueri saja tidak menyelesaikan masalah kinerja, pertimbangkan untuk menyesuaikan parameter konfigurasi ini:

  • temptable_max_ram- Mengontrol penggunaan RAM maksimum untuk tabel sementara.

  • temptable_max_mmap- Menetapkan batas untuk penyimpanan file yang dipetakan memori.

  • tmp_table_size- Berlaku saat aurora_tmptable_enable_per_table_limit diaktifkan (dinonaktifkan secara default).

penting

Perhatikan bahwa kondisi kueri tertentu akan selalu memerlukan tabel sementara pada disk, terlepas dari pengaturan konfigurasi. Untuk informasi selengkapnya mesin TempTable penyimpanan, lihat Menggunakan mesin TempTable penyimpanan di Amazon RDS for MySQL dan Amazon Aurora MySQL.

Tinjau kueri menggunakan INFORMATION_SCHEMA

Saat Anda menanyakan INFORMATION_SCHEMA tabel, MySQL membuat tabel sementara InnoDB pada volume cluster. Setiap sesi membutuhkan ruang meja sementara untuk tabel ini, yang dapat menyebabkan masalah kinerja selama akses bersamaan yang tinggi.

Untuk meningkatkan kinerja:

  • Gunakan PERFORMANCE_SCHEMA alih-alih INFORMATION_SCHEMA jika memungkinkan.

  • Jika Anda harus menggunakanINFORMATION_SCHEMA, kurangi seberapa sering Anda menjalankan kueri ini.

Meningkatkan parameter innodb_sync_array_size

innodb_sync_array_sizeParameter mengontrol ukuran array mutex/lock tunggu di MySQL. Nilai default 1 karya untuk beban kerja umum, tetapi meningkatkannya dapat mengurangi pertentangan utas selama konkurensi tinggi.

Saat beban kerja Anda menunjukkan peningkatan jumlah utas tunggu:

  • Pantau jumlah utas tunggu di beban kerja Anda.

  • Tetapkan innodb_sync_array_size sama dengan atau lebih tinggi dari jumlah vCPU instans Anda untuk membagi struktur koordinasi utas dan mengurangi pertengkaran.

catatan

Untuk menentukan jumlah v yang CPUs tersedia pada instans RDS Anda, lihat spesifikasi vCPU di jenis instans Amazon RDS.

Menerapkan penyatuan koneksi

MySQL menetapkan tablespace khusus untuk setiap sesi yang membuat tabel sementara. Tablespace ini tetap aktif sampai koneksi database berakhir. Untuk mengelola sumber daya Anda dengan lebih efisien:

  • Menerapkan penyatuan koneksi untuk membatasi jumlah ruang meja sementara yang aktif.

  • Gunakan kembali koneksi yang ada alih-alih membuat yang baru untuk setiap operasi.