Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# LWLock:lock\$1manajer
Peristiwa ini terjadi saat mesin Aurora PostgreSQL mempertahankan area memori kunci bersama untuk mengalokasikan, memeriksa, dan mendealokasikan kunci saat kunci jalur cepat tidak memungkinkan.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.lw-lock-manager.context.supported)
+ [Konteks](#apg-waits.lw-lock-manager.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.lw-lock-manager.causes)
+ [Tindakan](#apg-waits.lw-lock-manager.actions)
## 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 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 informasi selengkapnya tentang penguncian jalur cepat, lihat [jalur cepat](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) di README manajer kunci PostgreSQL dan [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html) pada dokumentasi PostgreSQL.
### 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:
1. Anda mengueri data dari rentang waktu beberapa hari, yang mengharuskan basis data untuk membaca banyak partisi.
1. 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.
1. 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 mengueri induk tanpa pemangkasan partisi yang tepat, basis data mungkin membuat ratusan atau bahkan ribuan kunci jalur yang tidak cepat. Biasanya, ketika konkurensi ini lebih tinggi dari jumlah vCPUs, acara `LWLock:lock_manager` tunggu muncul.
**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 mengueri 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
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Menggunakan pemangkasan partisi](#apg-waits.lw-lock-manager.actions.pruning)
+ [Hapus indeks yang tidak perlu](#apg-waits.lw-lock-manager.actions.indexes)
+ [Setel kueri Anda untuk penguncian jalur cepat](#apg-waits.lw-lock-manager.actions.tuning)
+ [Setel peristiwa tunggu lainnya](#apg-waits.lw-lock-manager.actions.other-waits)
+ [Kurangi bottleneck perangkat keras](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [Gunakan pooler koneksi](#apg-waits.lw-lock-manager.actions.pooler)
+ [Meningkatkan versi Aurora PostgreSQL Anda](#apg-waits.lw-lock-manager.actions.pg-version)
### 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 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](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) dalam dokumentasi PostgreSQL.
### 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](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) 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 di repositori](https://github.com/awslabs/pg-collector) AWS Labs GitHub .
### 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](https://aws.amazon.com/rds/instance-types/).
### 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 v CPUs untuk jenis instans Anda, lihat [Jenis Instans Amazon RDS](https://aws.amazon.com/rds/instance-types/).
Untuk informasi selengkapnya tentang pooling koneksi, lihat sumber daya berikut:
+ [Proksi Amazon RDS untuk Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Pool Koneksi dan Sumber Data](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) 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]( https://www.postgresql.org/docs/release/12.0/). Untuk informasi selengkapnya tentang meningkatkan Aurora PostgreSQL, lihat [Pembaruan mesin database untuk Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).