Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
LWLock:buffer_content () BufferContent
Peristiwa LWLock:buffer_content
terjadi saat suatu sesi menunggu untuk membaca atau menulis halaman data di memori, sementara sesi lain mengunci halaman tersebut untuk penulisan. Di Aurora PostgreSQL 13 dan versi yang lebih tinggi, peristiwa tunggu ini disebut BufferContent
.
Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
Konteks
Untuk membaca atau memanipulasi data, PostgreSQL mengaksesnya melalui buffer memori bersama. Untuk membaca dari buffer, proses mendapatkan lock (LWLock) ringan pada konten buffer dalam mode bersama. Untuk menulis ke buffer, proses ini mendapatkan kunci tersebut dalam mode eksklusif. Kunci bersama memungkinkan proses lain untuk secara konkuren memperoleh kunci bersama pada konten tersebut. Kunci eksklusif mencegah proses lain mendapatkan jenis kunci apa pun.
Peristiwa LWLock:buffer_content
(BufferContent
) menunjukkan bahwa beberapa proses mencoba untuk mendapatkan kunci ringan (LWLocks) pada konten buffer tertentu.
Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa LWLock:buffer_content
(BufferContent
) muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
- Peningkatan pembaruan konkuren ke data yang sama
-
Mungkin ada peningkatan jumlah sesi konkuren dengan kueri yang memperbarui konten buffer yang sama. Pertentangan ini bisa lebih terlihat pada tabel dengan banyak indeks.
- Data beban kerja tidak ada dalam memori
-
Saat data yang diproses oleh beban kerja aktif tidak ada dalam memori, peristiwa tunggu ini dapat meningkat. Efek ini karena proses memegang kunci dapat membuatnya lebih lama saat mereka melakukan I/O operasi disk.
- Penggunaan batasan kunci asing yang berlebihan
-
Batasan kunci asing dapat meningkatkan jumlah waktu saat sebuah proses memegang kunci konten buffer. Efek ini terjadi karena operasi baca memerlukan kunci konten buffer bersama pada kunci yang direferensikan saat kunci tersebut diperbarui.
Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Anda dapat mengidentifikasi peristiwa LWLock:buffer_content
(BufferContent
) dengan menggunakan Wawasan Performa Amazon RDS atau dengan mengueri tampilan pg_stat_activity
.
Topik
Meningkatkan efisiensi dalam memori
Untuk meningkatkan kemungkinan data beban kerja aktif ada di memori, partisi tabel atau naikkan skala kelas instans Anda. Untuk informasi tentang kelas instans DB, lihat Kelas instans Amazon Aurora DB.
Pantau BufferCacheHitRatio
metrik, yang mengukur persentase permintaan yang disajikan oleh cache buffer instans DB di cluster DB Anda. Metrik ini memberikan wawasan tentang jumlah data yang dilayani dari memori. Rasio hit yang tinggi menunjukkan bahwa instans DB Anda memiliki memori yang cukup untuk kumpulan data kerja Anda, sementara rasio rendah menunjukkan bahwa kueri Anda sering mengakses data dari penyimpanan.
Cache read hit per table dan cache read hit per index di bawah bagian Pengaturan memori dari laporan PG Collector
Kurangi penggunaan batasan kunci asing
Selidiki beban kerja yang mengalami jumlah peristiwa tunggu LWLock:buffer_content
(BufferContent
) yang tinggi untuk penggunaan batasan kunci asing. Hapus batasan kunci asing yang tidak perlu.
Hapus indeks yang tidak digunakan
Untuk beban kerja yang mengalami jumlah peristiwa tunggu LWLock:buffer_content
(BufferContent
) yang tinggi, identifikasi indeks yang tidak digunakan, lalu hapus.
Bagian indeks yang tidak digunakan dari laporan Kolektor PG
Hapus indeks duplikat
Identifikasi indeks duplikat dan hapus.
Bagian indeks duplikat dari laporan PG Collector
Drop atau REINDEX indeks tidak valid
Indeks tidak valid biasanya terjadi saat menggunakan CREATE INDEX CONCURRENTLY
atau REINDEX CONCURRENTLY
dan perintah gagal atau dibatalkan.
Indeks tidak valid tidak dapat digunakan untuk kueri, meskipun mereka masih akan diperbarui dan mengambil ruang disk.
Bagian indeks tidak valid dari laporan Kolektor PG
Gunakan indeks sebagian
Indeks sebagian dapat dimanfaatkan untuk meningkatkan kinerja kueri dan mengurangi ukuran indeks. Indeks paral adalah indeks yang dibangun di atas subset tabel, dengan subset ditentukan oleh ekspresi bersyarat. Sebagaimana dirinci dalam dokumentasi indeks sebagian
Hapus tabel dan indeks kembung
Tabel berlebihan dan indeks kembung dapat berdampak negatif pada kinerja database. Tabel dan indeks yang membengkak meningkatkan ukuran set kerja aktif, menurunkan efisiensi dalam memori. Selain itu, bloat meningkatkan biaya penyimpanan dan memperlambat eksekusi kueri. Untuk mendiagnosis kembung, lihat. Mendiagnosis bloat tabel dan indeks Selanjutnya, bagian Fragmentation (Bloat) dari laporan PG Collector
Untuk mengatasi tabel dan indeks kembung, ada beberapa opsi:
- VAKUM PENUH
-
VACUUM FULL
membuat salinan tabel baru, menyalin hanya tupel hidup, dan kemudian mengganti tabel lama dengan yang baru sambil memegang kunci.ACCESS EXCLUSIVE
Ini mencegah setiap membaca atau menulis ke meja, yang dapat menyebabkan pemadaman. Selain itu,VACUUM FULL
akan memakan waktu lebih lama jika meja besar. - pg_repack
-
pg_repack
Ini sangat membantu dalam situasi di manaVACUUM FULL
mungkin tidak cocok. Ini menciptakan tabel baru yang berisi data tabel kembung, melacak perubahan dari tabel asli, dan kemudian mengganti tabel asli dengan yang baru. Itu tidak mengunci tabel asli untuk operasi baca atau tulis saat sedang membangun tabel baru. Untuk informasi selengkapnya, untuk cara menggunakanpg_repack
, lihat Menghapus bloat dengan pg_repack dan pg_repack. - INDEKS ULANG
-
REINDEX
Perintah dapat dimanfaatkan untuk mengatasi indeks kembung.REINDEX
menulis versi baru dari indeks tanpa halaman mati atau halaman kosong atau hampir kosong, sehingga mengurangi konsumsi ruang indeks. Untuk informasi rinci tentangREINDEX
perintah, silakan merujuk ke dokumentasi REINDEX.
Setelah menghilangkan kembung dari tabel dan indeks, mungkin perlu untuk meningkatkan frekuensi autovacuum pada tabel tersebut. Menerapkan pengaturan autovacuum agresif di tingkat tabel dapat membantu mencegah terjadinya kembung di masa depan. Untuk informasi lebih lanjut, silakan merujuk ke dokumentasi di Vacuuming and analyzing tables
automatically
.