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
INACTIVEruang meja yang tersedia di kolam untuk digunakan kembali. -
Membuat 10 ruang tabel baru jika tidak ada
INACTIVEspasi.
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.
Topik
Pantau dan optimalkan penggunaan tabel sementara
Untuk memantau dan mengoptimalkan penggunaan tabel sementara, gunakan salah satu metode berikut:
-
Periksa
Created_tmp_disk_tablespenghitung 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
EXPLAINuntuk 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_limitdiaktifkan (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_SCHEMAalih-alihINFORMATION_SCHEMAjika memungkinkan. -
Jika Anda harus menggunakan
INFORMATION_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_sizesama 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.