

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

# synch/mutex/innodb/buf\$1pool\$1mutex
<a name="ams-waits.bufpoolmutex"></a>

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

**Topics**
+ [Versi mesin yang relevan](#ams-waits.bufpoolmutex.context.supported)
+ [Konteks](#ams-waits.bufpoolmutex.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.bufpoolmutex.causes)
+ [Tindakan](#ams-waits.bufpoolmutex.actions)

## Versi mesin yang relevan
<a name="ams-waits.bufpoolmutex.context.supported"></a>

Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora Versi saya 2 SQL

## Konteks
<a name="ams-waits.bufpoolmutex.context"></a>

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

Untuk informasi selengkapnya, lihat [Memantau InnoDB Mutex Waits Using Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) di dokumentasi Saya. SQL

## Kemungkinan penyebab peningkatan peristiwa tunggu
<a name="ams-waits.bufpoolmutex.causes"></a>

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
<a name="ams-waits.bufpoolmutex.actions"></a>

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

**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.bufpoolmutex.actions.identify)
+ [Menggunakan Wawasan Performa](#ams-waits.bufpoolmutex.actions.action1)
+ [Membuat Aurora Replicas](#ams-waits.bufpoolmutex.actions.action2)
+ [Memeriksa ukuran pool buffer](#ams-waits.bufpoolmutex.actions.action3)
+ [Memantau riwayat status global](#ams-waits.bufpoolmutex.actions.action4)

### Mengidentifikasi sesi dan kueri penyebab peristiwa
<a name="ams-waits.bufpoolmutex.actions.identify"></a>

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 SQL bagan Teratas di Konsol AWS Manajemen**

1. Buka RDS konsol Amazon 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 ditampilkan untuk instans DB tersebut.

1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.

1. **Di bawah bagan **beban Database**, pilih Top. SQL**

   Bagan mencantumkan SQL kueri yang bertanggung jawab atas pemuatan. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.

Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat posting blog Menganalisis Beban [Kerja SQL Saya Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.

### Menggunakan Wawasan Performa
<a name="ams-waits.bufpoolmutex.actions.action1"></a>

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.
+ Identifikasi SQL pernyataan yang bertanggung jawab atas acara 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
<a name="ams-waits.bufpoolmutex.actions.action2"></a>

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](Aurora.Integrating.AutoScaling.md).

### Memeriksa ukuran pool buffer
<a name="ams-waits.bufpoolmutex.actions.action3"></a>

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\$1Buffer\$1POOL\$1WAIT\$1FREE](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free) di dokumentasi Saya. SQL

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 My SQL secara otomatis menyesuaikan nilai `innodb_buffer_pool_instances` berdasarkan konfigurasi. `innodb_buffer_pool_size`

### Memantau riwayat status global
<a name="ams-waits.bufpoolmutex.actions.action4"></a>

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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).

Anda juga dapat membuat CloudWatch metrik Amazon khusus untuk memantau variabel status. Untuk informasi selengkapnya, lihat [Memublikasikan metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).