Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# synch/mutex/innodb/fil\_system\_mutex
Peristiwa `synch/mutex/innodb/fil_system_mutex` terjadi ketika sesi menunggu untuk mengakses cache memori tablespace.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Konteks](#ams-waits.innodb-fil-system-mutex.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.innodb-fil-system-mutex.causes)
+ [Tindakan](#ams-waits.innodb-fil-system-mutex.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
InnoDB menggunakan tablespace untuk mengelola area penyimpanan untuk tabel dan file log. *Cache memori tablespace* adalah struktur memori global yang memelihara informasi tentang tablespace. MySQL menggunakan peristiwa tunggu `synch/mutex/innodb/fil_system_mutex` untuk mengontrol akses bersamaan ke cache memori tablespace.
Peristiwa `synch/mutex/innodb/fil_system_mutex` menunjukkan bahwa saat ini ada lebih dari satu operasi yang perlu mengambil dan memanipulasi informasi dalam cache memori tablespace untuk tablespace yang sama.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `synch/mutex/innodb/fil_system_mutex` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, hal ini biasanya terjadi ketika terdapat semua kondisi berikut:
+ Peningkatan operasi bahasa manipulasi data (DML) bersamaan yang memperbarui atau menghapus data dalam tabel yang sama.
+ Tablespace untuk tabel ini sangat besar dan memiliki banyak halaman data.
+ Faktor pengisian untuk halaman data ini rendah.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Mengatur ulang tabel besar di luar jam sibuk](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### 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 Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa untuk instans DB tersebut akan muncul.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
Cara lain untuk mengetahui kueri yang menyebabkan tingginya jumlah peristiwa tunggu `synch/mutex/innodb/fil_system_mutex` adalah dengan memeriksa `performance_schema`, seperti pada contoh berikut.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Mengatur ulang tabel besar di luar jam sibuk
Atur ulang tabel besar yang Anda identifikasi sebagai sumber tingginya jumlah peristiwa tunggu `synch/mutex/innodb/fil_system_mutex` selama periode pemeliharaan di luar jam produksi. Dengan melakukannya, Anda akan memastikan bahwa pembersihan peta tablespace internal tidak terjadi saat akses cepat ke tabel sangat penting. Untuk informasi tentang cara mengatur ulang tabel, lihat [Pernyataan OPTIMIZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) dalam *Referensi MySQL*.