LWLock:buffer_content () BufferContent - Amazon Aurora

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.

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 dapat memberikan wawasan ke dalam tabel dan mengindeks rasio hit cache.

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 dapat memberikan wawasan tentang indeks yang tidak digunakan dalam database.

Hapus indeks duplikat

Identifikasi indeks duplikat dan hapus.

Bagian indeks duplikat dari laporan PG Collector dapat memberikan wawasan tentang indeks duplikat dalam database.

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 dapat memberikan wawasan tentang indeks yang tidak valid dalam database.

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, indeks sebagian dapat mengurangi overhead pemeliharaan indeks, karena PostgreSQL tidak perlu memperbarui indeks dalam semua kasus.

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 dapat memberikan wawasan tentang tabel dan indeks yang membengkak.

Untuk mengatasi tabel dan indeks kembung, ada beberapa opsi:

VAKUM PENUH

VACUUM FULLmembuat 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_repackIni sangat membantu dalam situasi di mana VACUUM 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

REINDEXPerintah dapat dimanfaatkan untuk mengatasi indeks kembung. REINDEXmenulis versi baru dari indeks tanpa halaman mati atau halaman kosong atau hampir kosong, sehingga mengurangi konsumsi ruang indeks. Untuk informasi rinci tentang REINDEXperintah, 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.