Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
LWLock:buffer_mapping
Peristiwa ini terjadi saat sesi menunggu untuk mengaitkan blok data dengan buffer di pool buffer bersama.
catatan
Peristiwa ini ditampilkan sebagai LWLock:buffer_mapping
di Aurora PostgreSQL versi 12 dan yang lebih rendah, serta LWLock:BufferMapping
di versi 13 dan yang lebih tinggi.
Versi mesin yang didukung
Informasi peristiwa tunggu ini relevan untuk Aurora PostgreSQL versi 9.6 dan yang lebih tinggi.
Konteks
Pool buffer bersama adalah area memori Aurora PostgreSQL yang memegang semua halaman yang sedang atau telah digunakan oleh proses. Saat memerlukan halaman, suatu proses membaca halaman ke dalam pool buffer bersama. Parameter shared_buffers
menetapkan ukuran buffer bersama dan menyimpan area memori untuk menyimpan tabel dan halaman indeks. Jika Anda mengubah parameter ini, pastikan untuk memulai ulang basis data. Untuk informasi selengkapnya, lihat Buffer bersama.
Peristiwa tunggu LWLock:buffer_mapping
terjadi dalam skenario berikut:
-
Suatu proses mencari tabel buffer untuk suatu halaman dan memperoleh kunci pemetaan buffer bersama.
-
Suatu proses memuat suatu halaman ke dalam pool buffer dan memperoleh kunci pemetaan buffer eksklusif.
-
Suatu proses menghapus suatu halaman dari pool dan memperoleh kunci pemetaan buffer eksklusif.
Penyebab
Saat peristiwa ini ditampilkan lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, basis data masuk dan keluar dari pool buffer bersama. Penyebab umumnya meliputi yang berikut:
-
Kueri yang besar
-
Bloat indeks dan tabel
-
Pemindaian tabel lengkap
-
Ukuran pool bersama yang lebih kecil dari set kerja
Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
Topik
Memantau metrik terkait buffer
Saat peristiwa tunggu LWLock:buffer_mapping
melonjak, selidiki rasio hit buffer. Anda dapat menggunakan metrik ini untuk mendapatkan pemahaman yang lebih baik tentang apa yang terjadi pada cache buffer. Periksa metrik berikut:
BufferCacheHitRatio
-
Metrik Amazon CloudWatch ini mengukur persentase permintaan yang dilayani oleh cache buffer instans DB pada klaster DB Anda. Anda mungkin melihat penurunan metrik ini sebelum peristiwa tunggu
LWLock:buffer_mapping
. blks_hit
-
Metrik penghitung Wawasan Performa ini menunjukkan jumlah blok yang diambil dari pool buffer bersama. Setelah peristiwa tunggu
LWLock:buffer_mapping
ditampilkan, Anda mungkin melihat lonjakan padablks_hit
. blks_read
-
Metrik penghitung Wawasan Performa ini menunjukkan jumlah blok yang memerlukan I/O untuk dibaca ke dalam pool buffer bersama. Anda mungkin melihat lonjakan pada
blks_read
sebelum peristiwa tungguLWLock:buffer_mapping
.
Menilai strategi pengindeksan
Untuk mengonfirmasi bahwa strategi pengindeksan tidak menurunkan performa, periksa hal berikut:
- Bloat indeks
-
Pastikan bloat indeks dan tabel tidak menyebabkan halaman yang tidak perlu turut dibaca ke buffer bersama. Jika tabel Anda berisi baris yang tidak digunakan, coba arsipkan data dan hapus baris dari tabel. Anda selanjutnya dapat membangun kembali indeks untuk tabel yang diubah ukurannya.
- Indeks untuk kueri yang sering digunakan
-
Untuk menentukan apakah Anda memiliki indeks optimal, pantau metrik mesin DB di Wawasan Performa. Metrik
tup_returned
menunjukkan jumlah baris yang dibaca. Metriktup_fetched
menunjukkan jumlah baris yang dikembalikan ke klien. Jikatup_returned
secara signifikan lebih besar daritup_fetched
, data mungkin tidak diindeks dengan benar. Selain itu, statistik tabel Anda mungkin tidak terkini.
Mengurangi jumlah buffer yang harus dialokasikan dengan cepat
Untuk mengurangi peristiwa tunggu LWLock:buffer_mapping
, coba kurangi jumlah buffer yang harus dialokasikan dengan cepat. Salah satu strateginya adalah dengan melakukan operasi batch yang lebih kecil. Anda mungkin dapat mencapai batch yang lebih kecil dengan partisi tabel.