LWLock:lock_manager

Peristiwa ini terjadi saat mesin Aurora 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 Aurora PostgreSQL versi 9.6 dan yang lebih tinggi.

Konteks

Saat Anda mengeluarkan pernyataan SQL, Aurora PostgreSQL mencatat kunci untuk melindungi struktur, data, dan integritas basis data Anda selama operasi bersamaan. Mesin dapat mencapai tujuan ini menggunakan kunci jalur cepat atau kunci jalur yang tidak cepat. Kunci jalur yang tidak cepat lebih mahal dan membuat lebih banyak overhead daripada kunci jalur cepat.

Penguncian jalur cepat

Untuk mengurangi overhead kunci yang sering diambil dan dilepaskan, tetapi jarang terjadi konflik, proses backend dapat menggunakan penguncian jalur cepat. Basis data menggunakan mekanisme ini untuk kunci yang memenuhi kriteria berikut:

• Menggunakan metode kunci DEFAULT.

• Mewakili kunci pada relasi basis data, bukan relasi bersama.

• Merupakan kunci lemah yang tidak mungkin bertentangan.

• Mesin dapat dengan cepat memverifikasi bahwa tidak ada kunci yang saling bertentangan.

Mesin tidak dapat menggunakan penguncian jalur cepat jika salah satu kondisi berikut ini benar:

• Kunci tidak memenuhi kriteria sebelumnya.

• Tidak ada lagi slot yang tersedia untuk proses backend.

Untuk informasi selengkapnya tentang penguncian jalur cepat, lihat jalur cepat di README manajer kunci PostgreSQL dan pg-locks pada dokumentasi PostgreSQL.

Contoh masalah penskalaan untuk manajer kunci

Pada contoh ini, tabel purchases menyimpan data selama lima tahun, yang dipartisi berdasarkan hari. Setiap partisi memiliki dua indeks. Urutan peristiwa berikut terjadi:

1. Anda membuat kueri data bernilai beberapa hari, yang memerlukan basis data untuk membaca banyak partisi.

2. Basis data membuat entri kunci untuk setiap partisi. Jika indeks partisi adalah bagian dari jalur akses pengoptimal, basis data akan membuat entri kunci untuk mereka juga.

3. Saat jumlah entri kunci yang diminta untuk proses backend yang sama lebih tinggi dari 16, yang merupakan nilai FP_LOCK_SLOTS_PER_BACKEND, manajer kunci menggunakan metode kunci jalur yang tidak cepat.

Aplikasi modern mungkin memiliki ratusan sesi. Jika sesi bersamaan membuat kueri 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. Sebaliknya, peristiwa tunggu 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 dari biasanya, mungkin menunjukkan masalah performa, kemungkinan penyebab lonjakan mendadak adalah berikut:

• Sesi aktif bersamaan menjalankan kueri yang tidak menggunakan kunci jalur cepat. Sesi ini juga melebihi vCPU maksimum.

• Sesi aktif bersamaan dalam jumlah besar mengakses tabel yang banyak dipartisi. Setiap partisi memiliki beberapa indeks.

• Basis data mengalami storm koneksi. Secara default, beberapa aplikasi dan perangkat lunak pool koneksi membuat lebih banyak koneksi saat basis data lambat. Hal ini memperburuk masalah. Sesuaikan perangkat lunak pool koneksi Anda sehingga storm koneksi tidak terjadi.

• Jumlah sesi yang besar membuat kueri tabel induk tanpa memangkas partisi.

• Data definition language (DDL), data manipulation language (DML), atau perintah pemeliharaan secara eksklusif mengunci relasi yang sibuk atau tuple yang sering diakses atau dimodifikasi.

Tindakan

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

Topik

• Menggunakan pemangkasan partisi
• Menghapus indeks yang tidak diperlukan
• Menyetel kueri untuk penguncian jalur cepat
• Menyetel untuk peristiwa tunggu lainnya
• Mengurangi masalah perangkat keras
• Menggunakan pooler koneksi
• Meningkatkan versi Aurora PostgreSQL Anda

Menggunakan pemangkasan partisi

Pemangkasan partisi adalah strategi pengoptimalan kueri yang mengecualikan partisi yang tidak dibutuhkan dari pemindaian tabel, sehingga meningkatkan performa. Pemangkasan partisi diaktifkan secara default. Jika tidak aktif, aktifkan dengan cara berikut:

SET enable_partition_pruning = on;

Kueri dapat memanfaatkan pemangkasan partisi saat klausa WHERE mereka berisi kolom yang digunakan untuk partisi. Untuk informasi selengkapnya, lihat Pemangkasan Partisi pada dokumentasi PostgreSQL.

Menghapus indeks yang tidak diperlukan

Basis data Anda mungkin berisi indeks yang tidak digunakan atau jarang digunakan. Jika ya, pertimbangkanlah untuk menghapusnya. Lakukan salah satu dari langkah berikut:

• Mempelajari cara menemukan indeks yang tidak perlu dengan membaca Indeks yang Tidak Digunakan di wiki PostgreSQL.

• Menjalankan PG Collector. Skrip SQL ini mengumpulkan informasi basis data dan menyajikannya dalam laporan HTML terkonsolidasi. Memeriksa bagian “Indeks yang tidak digunakan”. Untuk informasi selengkapnya, lihat pg-collector dalam repositori GitHub Lab AWS.

Menyetel kueri 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, cobalah kurangi jumlah relasi per kueri menjadi kurang dari 16.

Menyetel untuk peristiwa tunggu lainnya

Jika LWLock:lock_manager adalah yang pertama atau kedua dalam daftar peristiwa tunggu teratas, periksa apakah peristiwa tunggu berikut juga ditampilkan dalam daftar:

• Lock:Relation

• Lock:transactionid

• Lock:tuple

Jika peristiwa sebelumnya ditampilkan pada posisi tinggi dalam daftar, coba setel peristiwa tunggu ini terlebih dahulu. Peristiwa ini dapat menjadi pendorong untuk LWLock:lock_manager.

Mengurangi masalah perangkat keras

Anda mungkin memiliki masalah perangkat keras, seperti kekurangan CPU atau penggunaan maksimum bandwidth Amazon EBS. Jika demikian, coba kurangi masalah perangkat keras. Pertimbangkan tindakan berikut:

• Menaikkan skala kelas instans.

• Mengoptimalkan kueri yang mengonsumsi CPU dan memori dalam jumlah besar.

• Mengubah logika aplikasi.

• Mengarsipkan data.

Untuk informasi selengkapnya tentang CPU, memori, dan bandwidth jaringan EBS, lihat Jenis Instans Amazon RDS.

Menggunakan pooler koneksi

Jika jumlah total koneksi aktif Anda melebihi vCPU maksimum, lebih banyak proses OS memerlukan CPU daripada yang dapat didukung oleh jenis instans Anda. Jika demikian, pertimbangkanlah untuk menggunakan atau menyetel pool koneksi. Untuk informasi selengkapnya tentang vCPU untuk jenis instans Anda, lihat Jenis Instans Amazon RDS.

Untuk informasi selengkapnya tentang pengumpulan koneksi, lihat sumber daya berikut:

• Menggunakan Proksi Amazon RDS untuk Aurora

• pgbouncer

• Pool Koneksi dan Sumber Data pada Dokumentasi PostgreSQL

Meningkatkan versi Aurora PostgreSQL Anda

Jika versi Aurora PostgreSQL Anda saat ini lebih rendah dari 12, tingkatkan ke versi 12 atau yang lebih tinggi. PostgreSQL versi 12 dan 13 memiliki mekanisme partisi yang ditingkatkan. Untuk informasi selengkapnya tentang versi 12, lihat Catatan Rilis PostgreSQL 12.0. Untuk informasi selengkapnya tentang meningkatkan Aurora PostgreSQL, lihat Pembaruan Amazon Aurora PostgreSQL.