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

# LWLock:buffer\$1pemetaan
<a name="apg-waits.lwl-buffer-mapping"></a>

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.

**Topics**
+ [Versi mesin yang didukung](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Konteks](#apg-waits.lwl-buffer-mapping.context)
+ [Penyebab](#apg-waits.lwl-buffer-mapping.causes)
+ [Tindakan](#apg-waits.lwl-buffer-mapping.actions)

## Versi mesin yang didukung
<a name="apg-waits.lwl-buffer-mapping.context.supported"></a>

Informasi peristiwa tunggu ini relevan untuk Aurora PostgreSQL versi 9.6 dan yang lebih tinggi.

## Konteks
<a name="apg-waits.lwl-buffer-mapping.context"></a>

*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](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).

Peristiwa tunggu `LWLock:buffer_mapping` terjadi dalam skenario berikut:
+ Sebuah proses mencari tabel buffer untuk halaman dan memperoleh kunci pemetaan buffer bersama.
+ Sebuah proses memuat halaman ke dalam pool buffer dan memperoleh kunci pemetaan buffer eksklusif.
+ Sebuah proses menghapus halaman dari pool dan memperoleh kunci pemetaan buffer eksklusif.

## Penyebab
<a name="apg-waits.lwl-buffer-mapping.causes"></a>

Ketika peristiwa ini muncul lebih sering dari biasanya, yang mungkin menunjukkan masalah performa, basis data akan melakukan paging masuk dan keluar pada pool buffer bersama. Penyebab umumnya meliputi yang berikut:
+ Kueri besar
+ Indeks dan tabel yang mengalami bloat
+ Pemindaian tabel lengkap
+ Ukuran pool bersama yang lebih kecil dari working set

## Tindakan
<a name="apg-waits.lwl-buffer-mapping.actions"></a>

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

**Topics**
+ [Pantau metrik terkait buffer](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Evaluasi strategi pengindeksan Anda](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Kurangi jumlah buffer yang harus dialokasikan dengan cepat](#apg-waits.lwl-buffer-mapping.actions.buffers)

### Pantau metrik terkait buffer
<a name="apg-waits.lwl-buffer-mapping.actions.monitor-metrics"></a>

Saat `LWLock:buffer_mapping` menunggu lonjakan, selidiki rasio hit buffer. Anda dapat menggunakan metrik ini untuk mendapatkan pemahaman yang lebih baik tentang apa yang terjadi di cache buffer. Periksa metrik berikut:

`BufferCacheHitRatio`  
 CloudWatch Metrik Amazon ini mengukur persentase permintaan yang disajikan oleh cache buffer instans DB di cluster 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` muncul, Anda mungkin melihat lonjakan `blks_hit`.

`blks_read`  
Metrik penghitung Performance Insights ini menunjukkan jumlah blok yang perlu dibaca I/O ke dalam kumpulan buffer bersama. Anda mungkin melihat lonjakan `blks_read` menjelang peristiwa tunggu `LWLock:buffer_mapping`.

### Evaluasi strategi pengindeksan Anda
<a name="apg-waits.lwl-buffer-mapping.actions.indexes"></a>

Untuk mengonfirmasi bahwa strategi pengindeksan Anda tidak menurunkan performa, periksa hal berikut:

Bloat indeks  
Pastikan bloat indeks dan tabel tidak menyebabkan halaman yang tidak perlu dibacakan ke buffer bersama. Jika tabel Anda berisi baris yang tidak digunakan, pertimbangkan untuk mengarsipkan datanya dan menghapus baris tersebut dari tabel. Anda kemudian dapat membuat 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. Metrik `tup_fetched` menunjukkan jumlah baris yang dikembalikan ke klien. Jika `tup_returned` secara signifikan lebih besar dari `tup_fetched`, data mungkin tidak diindeks dengan benar. Selain itu, statistik tabel Anda mungkin tidak terkini.

### Kurangi jumlah buffer yang harus dialokasikan dengan cepat
<a name="apg-waits.lwl-buffer-mapping.actions.buffers"></a>

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 memiliki batch yang lebih kecil dengan mempartisi tabel Anda.