Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
LWLock:lock_manager (LWLock:lockmanager)
Peristiwa ini terjadi saat mesin RDS for PostgreSQL mempertahankan area memori kunci bersama untuk mengalokasikan, memeriksa, dan mendealokasikan kunci saat kunci jalur cepat tidak memungkinkan.
Versi mesin yang didukung
Informasi peristiwa tunggu ini relevan untuk RDS for PostgreSQL versi 9.6 dan lebih tinggi. Untuk rilis RDS for PostgreSQL yang lebih lama dari versi 13, nama peristiwa tunggu ini adalah LWLock:lock_manager. Untuk RDS for PostgreSQL versi 13 dan yang lebih tinggi, nama peristiwa tunggu ini adalah LWLock:lockmanager.
Konteks
Saat Anda mengeluarkan pernyataan SQL, RDS for PostgreSQL mencatat kunci untuk melindungi struktur, data, dan integritas basis data Anda selama operasi konkuren. Mesin dapat mencapai tujuan ini menggunakan kunci jalur cepat atau kunci jalur yang tidak cepat. Kunci jalur yang tidak cepat lebih mahal dan menghasilkan lebih banyak overhead daripada kunci jalur cepat.
Penguncian jalur cepat
Untuk mengurangi overhead kunci yang sering diambil dan dilepaskan, tetapi jarang bertentangan, proses backend dapat menggunakan penguncian jalur cepat. Basis data menggunakan mekanisme ini untuk kunci yang memenuhi kriteria berikut:
-
Kunci tersebut menggunakan metode kunci DEFAULT.
-
Kunci tersebut merepresentasikan kunci pada relasi basis data, bukan relasi bersama.
-
Kunci tersebut adalah kunci lemah yang tidak mungkin bertentangan.
-
Mesin dapat dengan cepat memverifikasi bahwa tidak ada kunci yang mungkin dapat bertentangan.
Mesin tidak dapat menggunakan penguncian jalur cepat jika salah satu kondisi berikut ini berlaku:
-
Kunci tidak memenuhi kriteria di atas.
-
Tidak ada lagi slot yang tersedia untuk proses backend.
Untuk menyetel kueri Anda untuk penguncian jalur cepat, Anda dapat menggunakan kueri berikut.
SELECT count(*), pid, mode, fastpath FROM pg_locks WHERE fastpath IS NOT NULL GROUP BY 4,3,2 ORDER BY pid, mode;count | pid | mode | fastpath -------+------+-----------------+---------- 16 | 9185 | AccessShareLock | t 336 | 9185 | AccessShareLock | f 1 | 9185 | ExclusiveLock | t
Kueri berikut hanya menunjukkan total di seluruh basis data.
SELECT count(*), mode, fastpath FROM pg_locks WHERE fastpath IS NOT NULL GROUP BY 3,2 ORDER BY mode,1;count | mode | fastpath -------+-----------------+---------- 16 | AccessShareLock | t 337 | AccessShareLock | f 1 | ExclusiveLock | t (3 rows)
Untuk informasi selengkapnya tentang penguncian jalur cepat, lihat fast path
Contoh masalah penskalaan untuk pengelola kunci
Dalam contoh ini, tabel bernama purchases menyimpan data dari rentang waktu lima tahun, yang dipartisi berdasarkan hari. Setiap partisi memiliki dua indeks. Urutan peristiwa berikut terjadi:
-
Anda mengkueri data dari rentang waktu beberapa hari, yang mengharuskan basis data untuk membaca banyak partisi.
-
Basis data membuat entri kunci untuk setiap partisi. Jika indeks partisi adalah bagian dari jalur akses pengoptimisasi, basis data juga akan membuat entri kunci untuk indeks tersebut.
-
Saat jumlah entri kunci yang diminta untuk proses backend yang sama lebih tinggi dari 16, yang merupakan nilai
FP_LOCK_SLOTS_PER_BACKEND, pengelola kunci menggunakan metode kunci jalur yang tidak cepat.
Aplikasi modern mungkin memiliki ratusan sesi. Jika sesi konkuren mengkueri induk tanpa pemangkasan partisi yang tepat, basis data mungkin membuat ratusan atau bahkan ribuan kunci jalur yang tidak cepat. Biasanya, saat konkurensi ini lebih tinggi dari jumlah vCPU, peristiwa tunggu LWLock:lock_manager akan ditampilkan.
catatan
Peristiwa tunggu LWLock:lock_manager tidak terkait dengan jumlah partisi atau indeks dalam skema basis data. Sebagai gantinya, hal ini terkait dengan jumlah kunci jalur yang tidak cepat yang harus dikontrol oleh basis data.
Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa tunggu LWLock:lock_manager terjadi lebih sering dari biasanya, yang mungkin menunjukkan masalah performa, kemungkinan penyebab lonjakan yang mendadak ini adalah sebagai berikut:
-
Sesi aktif konkuren menjalankan kueri yang tidak menggunakan kunci jalur cepat. Sesi ini juga melebihi vCPU maksimum.
-
Sejumlah besar sesi aktif konkuren mengakses tabel yang memiliki banyak partisi. Setiap partisi memiliki beberapa indeks.
-
Basis data mengalami badai koneksi. Secara default, beberapa aplikasi dan perangkat lunak pool koneksi akan membuat lebih banyak koneksi ketika basis data lambat. Praktik ini memperburuk masalahnya. Setel perangkat lunak pool koneksi Anda sehingga badai koneksi tidak terjadi.
-
Sejumlah besar sesi mengkueri tabel induk tanpa memangkas partisi.
-
Bahasa definisi data (DL), bahasa manipulasi data (DL), atau perintah pemeliharaan secara khusus mengunci relasi sibuk atau tuple yang sering diakses atau dimodifikasi.
Tindakan
Jika peristiwa tunggu CPU terjadi, hal ini tidak selalu menunjukkan masalah performa. Tanggapi peristiwa ini hanya ketika performa menurun dan peristiwa tunggu ini mendominasi beban DB.
Topik
Gunakan pemangkasan partisi
Pemangkasan partisi adalah strategi optimisasi kueri untuk tabel yang dipartisi secara deklaratif yang mengecualikan partisi yang tidak dibutuhkan dari pemindaian tabel, sehingga meningkatkan performa. Pemangkasan partisi diaktifkan secara default. Jika dinonaktifkan, aktifkan sebagai berikut.
SET enable_partition_pruning = on;
Kueri dapat memanfaatkan pemangkasan partisi ketika klausa WHERE-nya berisi kolom yang digunakan untuk pembuatan partisi. Untuk informasi selengkapnya, lihat Partition Pruning
Hapus indeks yang tidak perlu
Basis data Anda mungkin berisi indeks yang tidak digunakan atau jarang digunakan. Jika demikian, pertimbangkan untuk menghapusnya. Lakukan salah satu dari langkah berikut:
-
Pelajari cara menemukan indeks yang tidak perlu dengan membaca Indeks yang Tidak Digunakan
di wiki PostgreSQL. -
Jalankan PG Collector. Skrip SQL ini mengumpulkan informasi basis data dan menyajikannya dalam laporan HTML terkonsolidasi. Periksa bagian “Indeks yang tidak digunakan”. Untuk informasi selengkapnya, lihat pg-collector
dalam Repositori GitHub Lab AWS.
Setel kueri Anda untuk penguncian jalur cepat
Untuk mengetahui apakah kueri Anda menggunakan penguncian jalur cepat, buat kueri pada kolom fastpath dalam tabel pg_locks. Jika kueri Anda tidak menggunakan penguncian jalur cepat, coba kurangi jumlah relasi per kueri menjadi kurang dari 16.
Setel peristiwa tunggu lainnya
Jika LWLock:lock_manager adalah yang pertama atau kedua dalam daftar peristiwa tunggu teratas, periksa apakah peristiwa tunggu berikut juga ditampilkan pada daftar ini:
-
Lock:Relation -
Lock:transactionid -
Lock:tuple
Jika peristiwa di atas ditampilkan pada posisi tinggi dalam daftar, pertimbangkan untuk menyetel peristiwa tunggu ini terlebih dahulu. Peristiwa ini dapat menjadi pendorong untuk LWLock:lock_manager.
Kurangi bottleneck perangkat keras
Anda mungkin memiliki bottleneck perangkat keras, seperti kelaparan CPU atau penggunaan maksimum bandwidth Amazon EBS Anda. Jika demikian, maka pertimbangkan untuk mengurangi bottleneck perangkat keras. Pertimbangkan tindakan berikut:
-
Naikkan kelas instans Anda.
-
Optimalkan kueri yang mengonsumsi CPU dan memori dalam jumlah besar.
-
Ubah logika aplikasi Anda.
-
Arsipkan data Anda.
Untuk informasi selengkapnya tentang CPU, memori, dan bandwidth jaringan EBS, lihat Jenis Instans Amazon RDS
Gunakan pooler koneksi
Jika jumlah total koneksi aktif Anda melebihi vCPU maksimum, lebih banyak proses OS akan memerlukan CPU yang melampaui kapasitas yang dapat didukung oleh jenis instans Anda. Jika demikian, pertimbangkan untuk menggunakan atau menyetel pool koneksi. Untuk informasi selengkapnya tentang vCPU untuk jenis instans Anda, lihat Jenis Instans Amazon RDS
Untuk informasi selengkapnya tentang pooling koneksi, lihat sumber daya berikut:
-
Connection Pools and Data Sources
dalam dokumentasi PostgreSQL
Upgrade versi RDS for PostgreSQL Anda
Jika versi RDS for PostgreSQL Anda saat ini lebih rendah dari 12, upgrade ke versi 12 atau lebih tinggi. PostgreSQL versi 12 dan yang lebih baru memiliki mekanisme partisi yang ditingkatkan. Untuk informasi selengkapnya tentang versi 12, lihat Catatan Rilis PostgreSQL 12.0
