;
```
Jika menonaktifkan paralelisme menghasilkan hasil yang lebih baik atau lebih konsisten, pertimbangkan untuk menonaktifkannya untuk kueri tertentu di tingkat sesi menggunakan perintah SET. Untuk dampak yang lebih luas, Anda mungkin ingin menonaktifkan paralelisme di tingkat instans dengan menyesuaikan parameter yang relevan di cluster atau grup parameter instance Anda. Untuk informasi selengkapnya, lihat [Parameter Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.ParameterGroups.md).
### Pantau penggunaan kueri paralel
Gunakan kueri berikut untuk mendapatkan visibilitas ke aktivitas dan kapasitas kueri paralel:
Periksa proses pekerja paralel aktif:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Kueri ini menunjukkan jumlah proses pekerja paralel aktif. Nilai tinggi mungkin menunjukkan bahwa `max\$1parallel\$1workers` Anda dikonfigurasi dengan nilai tinggi dan Anda mungkin ingin mempertimbangkan untuk menguranginya.
Periksa kueri paralel bersamaan:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Kueri ini mengembalikan jumlah proses pemimpin berbeda yang telah meluncurkan query paralel. Angka yang tinggi di sini menunjukkan bahwa beberapa sesi menjalankan query paralel secara bersamaan, yang dapat meningkatkan permintaan pada CPU dan memori.
### Tinjau dan sesuaikan pengaturan kueri paralel
Tinjau parameter berikut untuk memastikan parameter tersebut selaras dengan beban kerja Anda:
+ `max_parallel_workers`: Jumlah total pekerja paralel di semua sesi.
+ `max_parallel_workers_per_gather`: Pekerja maks per kueri.
Untuk beban kerja OLAP, meningkatkan nilai-nilai ini dapat meningkatkan kinerja. Untuk beban kerja OLTP, nilai yang lebih rendah umumnya lebih disukai.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimalkan alokasi sumber daya
Pantau pemanfaatan CPU dan pertimbangkan untuk menyesuaikan jumlah v CPUs jika secara konsisten tinggi dan jika aplikasi Anda mendapat manfaat dari query paralel. Pastikan memori yang memadai tersedia untuk operasi paralel.
+ Gunakan metrik Performance Insights untuk menentukan apakah sistem terikat CPU.
+ Setiap pekerja paralel menggunakan miliknya sendiri`work_mem`. Pastikan penggunaan memori total berada dalam batas instans.
Query paralel dapat mengkonsumsi sumber daya yang jauh lebih banyak daripada query non-paralel, karena setiap proses pekerja adalah proses yang benar-benar terpisah yang memiliki dampak yang kira-kira sama pada sistem sebagai sesi pengguna tambahan. Ini harus diperhitungkan saat memilih nilai untuk pengaturan ini, serta saat mengonfigurasi pengaturan lain yang mengontrol pemanfaatan sumber daya, seperti. `work_mem` Untuk informasi selengkapnya, lihat [Dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Batas sumber daya seperti `work_mem` diterapkan secara individual untuk setiap pekerja, yang berarti total pemanfaatan mungkin jauh lebih tinggi di semua proses daripada biasanya untuk setiap proses tunggal.
Pertimbangkan untuk meningkatkan v CPUs atau menyetel parameter memori jika beban kerja Anda sangat paralel.
### Selidiki manajemen koneksi
Jika mengalami kelelahan koneksi, tinjau strategi penyatuan koneksi aplikasi. Pertimbangkan untuk menerapkan penyatuan koneksi di tingkat aplikasi jika belum digunakan.
### Meninjau dan mengoptimalkan operasi pemeliharaan
Koordinasikan pembuatan indeks dan tugas pemeliharaan lainnya untuk mencegah pertentangan sumber daya. Pertimbangkan untuk menjadwalkan operasi ini selama jam-jam di luar sibuk. Hindari penjadwalan pemeliharaan berat (misalnya, pembuatan indeks paralel) selama periode beban kueri pengguna yang tinggi. Operasi ini dapat mengkonsumsi pekerja paralel dan memengaruhi kinerja untuk kueri reguler.
### Memanfaatkan Query Plan Management (QPM)
Di Aurora PostgreSQL, fitur Query Plan Management (QPM) dirancang untuk memastikan kemampuan beradaptasi dan stabilitas rencana, terlepas dari perubahan lingkungan database yang dapat menyebabkan regresi rencana kueri. Untuk informasi selengkapnya, lihat [Gambaran umum manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md) .QPM menyediakan beberapa kontrol atas pengoptimal. Tinjau rencana yang disetujui di QPM untuk memastikan mereka selaras dengan pengaturan paralelisme saat ini. Perbarui atau hapus rencana usang yang mungkin memaksa eksekusi paralel suboptimal.
Anda juga dapat memperbaiki rencana menggunakan pg\$1hint\$1plan. Untuk informasi selengkapnya, lihat [Memperbaiki rencana menggunakan pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Anda dapat menggunakan petunjuk bernama `Parallel` untuk menegakkan eksekusi paralel. Untuk informasi selengkapnya, lihat [Petunjuk untuk rencana paralel](https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_table.md#hints-for-parallel-plans).
# IPC: ProcArrayGroupUpdate
`IPC:ProcArrayGroupUpdate`Peristiwa terjadi ketika sesi menunggu pemimpin grup untuk memperbarui status transaksi di akhir operasi itu. Sementara PostgreSQL umumnya mengaitkan peristiwa tunggu tipe IPC dengan operasi query paralel, acara tunggu khusus ini tidak spesifik untuk query paralel.
**Topics**
+ [Versi mesin yang didukung](#apg-rpg-ipcprocarraygroup.supported)
+ [Konteks](#apg-rpg-ipcprocarraygroup.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-rpg-ipcprocarraygroup.causes)
+ [Tindakan](#apg-rpg-ipcprocarraygroup.actions)
## Versi mesin yang didukung
Informasi acara tunggu ini didukung untuk semua versi .
## Konteks
**Memahami array proses - Array** process (proc) adalah struktur memori bersama di PostgreSQL. Ini menyimpan informasi tentang semua proses yang berjalan, termasuk rincian transaksi. Selama penyelesaian transaksi (`COMMIT`atau`ROLLBACK`), ProcArray perlu diperbarui untuk mencerminkan perubahan dan menghapus TransactionId dari array. Sesi yang mencoba menyelesaikan transaksinya harus memperoleh kunci eksklusif pada. ProcArray Ini mencegah proses lain mendapatkan kunci bersama atau eksklusif di atasnya.
**Mekanisme pembaruan grup** — Saat melakukan COMMIT atau ROLLBACK, jika proses backend tidak dapat memperoleh mode eksklusif, ia memperbarui ProcArrayLock bidang khusus yang disebut. ProcArrayGroupMember Ini menambahkan transaksi ke daftar sesi yang berniat untuk berakhir. Proses backend ini kemudian tidur dan waktu tidurnya diinstrumentasi sebagai acara tunggu. ProcArrayGroupUpdate Proses pertama dalam ProcArray dengan procArrayGroup Anggota, yang disebut sebagai proses pemimpin, memperoleh ProcArrayLock mode eksklusif. Kemudian membersihkan daftar proses yang menunggu kliring TransactionId grup. Setelah ini selesai, pemimpin melepaskan ProcArrayLock dan kemudian membangunkan semua proses dalam daftar ini, memberi tahu mereka bahwa transaksi mereka selesai.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Semakin banyak proses yang berjalan, semakin lama seorang pemimpin akan berpegang pada mode eksklusif. procArrayLock Akibatnya, semakin banyak transaksi tulis berakhir dalam skenario pembaruan grup yang menyebabkan potensi tumpukan proses menunggu acara `ProcArrayGroupUpdate` tunggu. Dalam tampilan SQL Top Database Insights, Anda akan melihat bahwa COMMIT adalah pernyataan dengan sebagian besar acara tunggu ini. Ini diharapkan tetapi akan membutuhkan penyelidikan lebih dalam ke SQL tulis spesifik yang dijalankan untuk menentukan tindakan apa yang tepat untuk diambil.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Identifikasi `IPC:ProcArrayGroupUpdate` peristiwa menggunakan Amazon RDS Performance Insights atau dengan menanyakan tampilan sistem PostgreSQL. `pg_stat_activity`
**Topics**
+ [Memantau transaksi komit dan operasi rollback](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Mengurangi konkurensi](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Menerapkan penyatuan koneksi](#apg-rpg-ipcprocarraygroup.actions.pooling)
### Memantau transaksi komit dan operasi rollback
**Monitor commit dan rollback** — Peningkatan jumlah commit dan rollback dapat menyebabkan peningkatan tekanan pada. ProcArray Misalnya, jika pernyataan SQL mulai gagal karena meningkatnya pelanggaran kunci duplikat, Anda mungkin melihat peningkatan rollback yang dapat meningkatkan ProcArray pertengkaran dan kembung tabel.
Amazon RDS Database Insights menyediakan metrik PostgreSQL dan melaporkan jumlah commit `xact_commit` dan rollback `xact_rollback` per detik.
### Mengurangi konkurensi
**Transaksi batching** — Jika memungkinkan, operasi batch dalam transaksi tunggal untuk mengurangi commit/rollback operasi.
**Batasi konkurensi** — Kurangi jumlah transaksi yang aktif secara bersamaan untuk mengurangi perselisihan kunci pada. ProcArray Meskipun akan memerlukan beberapa pengujian, mengurangi jumlah total koneksi bersamaan dapat mengurangi pertengkaran dan mempertahankan throughput.
### Menerapkan penyatuan koneksi
**Solusi pengumpulan koneksi** - Gunakan penyatuan koneksi untuk mengelola koneksi database secara efisien, mengurangi jumlah total backend dan karenanya beban kerja pada file. ProcArray Meskipun akan memerlukan beberapa pengujian, mengurangi jumlah total koneksi bersamaan dapat mengurangi pertengkaran dan mempertahankan throughput.
Untuk informasi lebih lanjut, lihat Penggabungan [koneksi untuk Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.connection_pooling.html).
**Mengurangi badai koneksi** — Demikian pula, pola sering membuat dan mengakhiri koneksi menyebabkan tekanan tambahan pada koneksi. ProcArray Dengan mengurangi pola ini, perselisihan keseluruhan berkurang.
# Lock:advisory
Peristiwa `Lock:advisory` terjadi saat aplikasi PostgreSQL menggunakan kunci untuk mengoordinasi aktivitas di beberapa sesi.
**Topics**
+ [Versi mesin yang relevan](#apg-waits.lockadvisory.context.supported)
+ [Konteks](#apg-waits.lockadvisory.context)
+ [Penyebab](#apg-waits.lockadvisory.causes)
+ [Tindakan](#apg-waits.lockadvisory.actions)
## Versi mesin yang relevan
Informasi peristiwa tunggu ini relevan untuk Aurora PostgreSQL versi 9.6 dan yang lebih tinggi.
## Konteks
Kunci penasihat PostgreSQL adalah kunci kooperatif tingkat aplikasi yang secara eksplisit dikunci dan dibuka oleh kode aplikasi pengguna. Aplikasi dapat menggunakan kunci penasihat PostgreSQL untuk mengoordinasi aktivitas di beberapa sesi. Tidak seperti kunci biasa tingkat objek atau baris, aplikasi memiliki kontrol penuh atas masa pakai kunci. Untuk informasi selengkapnya, lihat [Kunci Penasihat](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) dalam dokumentasi PostgreSQL.
Kunci penasihat dapat dilepaskan sebelum transaksi berakhir atau disimpan oleh sesi di seluruh transaksi. Ini tidak berlaku untuk kunci implisit yang diberlakukan sistem, seperti kunci eksklusif akses pada tabel yang diperoleh dari pernyataan `CREATE INDEX`.
Untuk deskripsi fungsi yang digunakan untuk memperoleh (mengunci) dan melepaskan (membuka kunci) kunci penasihat, lihat [Fungsi Kunci Penasihat](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) dalam dokumentasi PostgreSQL.
Kunci penasihat diterapkan di atas sistem penguncian PostgreSQL biasa dan terlihat dalam tampilan sistem `pg_locks`.
## Penyebab
Jenis kunci ini secara eksklusif dikendalikan oleh aplikasi yang menggunakannya secara eksplisit. Kunci penasihat yang diperoleh untuk setiap baris sebagai bagian dari kueri dapat menyebabkan lonjakan kunci atau penumpukan jangka panjang.
Efek ini terjadi saat kueri dijalankan dengan cara yang memperoleh kunci pada lebih banyak baris daripada yang ditampilkan oleh kueri. Aplikasi pada akhirnya harus melepaskan setiap kunci, tetapi jika kunci diperoleh pada baris yang tidak ditampilkan, maka aplikasi tidak dapat menemukan semua kunci.
Contoh berikut berasal dari [Kunci Penasihat](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) dalam dokumentasi PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
Dalam contoh ini, klausa `LIMIT` hanya dapat menghentikan output kueri setelah baris dipilih secara internal dan nilai ID-nya dikunci. Hal ini dapat terjadi secara tiba-tiba saat volume data yang berkembang menyebabkan perencana memilih rencana eksekusi lain yang tidak diuji selama pengembangan. Penumpukan dalam kasus ini terjadi karena aplikasi secara eksplisit memanggil `pg_advisory_unlock` untuk setiap nilai ID yang terkunci. Namun, dalam kasus ini, aplikasi tidak dapat menemukan set kunci yang diperoleh pada baris yang tidak ditampilkan. Karena diperoleh pada tingkat sesi, kunci tidak dilepaskan secara otomatis pada akhir transaksi.
Kemungkinan penyebab lain untuk lonjakan upaya kunci yang diblokir adalah konflik yang tidak diinginkan. Dalam konflik ini, bagian aplikasi yang tidak terkait berbagi ruang ID kunci yang sama secara tidak sengaja.
## Tindakan
Tinjau penggunaan kunci penasihat oleh aplikasi dan jelaskan secara detail di mana dan kapan dalam alur aplikasi setiap jenis kunci penasihat diperoleh dan dilepaskan.
Ketahui apakah sesi memperoleh terlalu banyak kunci atau sesi yang berjalan lama tidak melepaskan kunci cukup awal, sehingga mengarah ke penumpukan kunci yang lambat. Anda dapat memperbaiki penumpukan kunci tingkat sesi yang lambat dengan mengakhiri sesi menggunakan `pg_terminate_backend(pid)`.
Klien yang menunggu kunci penasihat muncul dalam `pg_stat_activity` dengan `wait_event_type=Lock` dan `wait_event=advisory`. Anda dapat memperoleh nilai kunci tertentu dengan membuat kueri tampilan sistem `pg_locks` untuk `pid` yang sama, dengan mencari `locktype=advisory` dan `granted=f`.
Anda kemudian dapat mengidentifikasi sesi pemblokiran dengan membuat kueri `pg_locks` untuk kunci penasihat serupa yang memiliki `granted=t`, seperti ditunjukkan dalam contoh berikut.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Semua fungsi API kunci penasihat memiliki dua set argumen, baik satu argumen `bigint` atau dua argumen `integer`:
+ Untuk fungsi API dengan satu argumen `bigint`, 32 bit atas masuk dalam `pg_locks.classid` dan 32 bit bawah masuk dalam `pg_locks.objid`.
+ Untuk fungsi API dengan dua argumen `integer`, argumen pertama adalah `pg_locks.classid` dan argumen kedua adalah `pg_locks.objid`.
Nilai `pg_locks.objsubid` menunjukkan formulir API yang digunakan: `1` berarti satu argumen `bigint`; `2` berarti dua argumen `integer`.
# Lock:extend
Peristiwa `Lock:extend` terjadi saat suatu proses backend sedang menunggu untuk mengunci relasi agar dapat diperluas, sementara proses lain mengunci relasi tersebut untuk tujuan yang sama.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.lockextend.context.supported)
+ [Konteks](#apg-waits.lockextend.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.lockextend.causes)
+ [Tindakan](#apg-waits.lockextend.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
Peristiwa `Lock:extend` menunjukkan bahwa suatu proses backend sedang menunggu untuk memperluas relasi yang dikunci oleh proses backend lain saat relasi tersebut diperluas. Karena hanya satu proses pada satu waktu yang dapat memperluas relasi, sistem membuat peristiwa tunggu `Lock:extend`. Operasi `INSERT`, `COPY`, dan `UPDATE` dapat membuat peristiwa ini.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `Lock:extend` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Lonjakan sisipan atau pembaruan bersamaan ke tabel yang sama **
Mungkin terdapat peningkatan jumlah sesi bersamaan dengan kueri yang disisipkan ke atau memperbarui tabel yang sama.
**Bandwidth jaringan tidak cukup**
Bandwidth jaringan pada instans DB mungkin tidak cukup untuk kebutuhan komunikasi penyimpanan dari beban kerja saat ini. Hal ini dapat berkontribusi pada latensi penyimpanan yang menyebabkan peningkatan peristiwa `Lock:extend`.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengurangi sisipan dan pembaruan bersamaan ke relasi yang sama](#apg-waits.lockextend.actions.action1)
+ [Meningkatkan bandwidth jaringan](#apg-waits.lockextend.actions.increase-network-bandwidth)
### Mengurangi sisipan dan pembaruan bersamaan ke relasi yang sama
Pertama, ketahui apakah terdapat peningkatan pada metrik `tup_inserted` dan `tup_updated` dengan disertai peningkatan pada peristiwa tunggu ini. Jika demikian, periksa relasi yang memiliki pertentangan tinggi untuk operasi penyisipan dan pembaruan. Untuk menentukan hal ini, buat kueri tampilan `pg_stat_all_tables` untuk nilai pada bidang `n_tup_ins` dan `n_tup_upd`. Untuk informasi tentang tampilan `pg_stat_all_tables`, lihat [pg\$1stat\$1statements](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) pada dokumentasi PostgreSQL.
Untuk mendapatkan informasi selengkapnya tentang pemblokiran dan kueri yang diblokir, buat kueri `pg_stat_activity` seperti contoh berikut:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Setelah Anda mengidentifikasi relasi yang berkontribusi untuk meningkatkan peristiwa `Lock:extend`, gunakan teknik berikut untuk mengurangi pertentangan:
+ Cari tahu apakah Anda dapat menggunakan partisi untuk mengurangi pertentangan pada tabel yang sama. Memisahkan tuple yang disisipkan atau diperbarui ke dalam partisi yang berbeda dapat mengurangi pertentangan. Untuk informasi tentang partisi, lihat [Mengelola partisi PostgreSQL dengan ekstensi pg\$1partman](PostgreSQL_Partitions.md).
+ Jika peristiwa tunggu terutama disebabkan oleh aktivitas pembaruan, pertimbangkan untuk mengurangi nilai faktor isi relasi. Ini dapat mengurangi permintaan untuk blok baru selama pembaruan. Faktor isi adalah parameter penyimpanan untuk tabel yang menentukan jumlah maksimum ruang untuk mengemas halaman tabel. Ini dinyatakan sebagai persentase dari total ruang untuk sebuah halaman. Untuk informasi selengkapnya tentang parameter faktor isi, lihat [BUAT TABEL](https://www.postgresql.org/docs/13/sql-createtable.html) pada dokumentasi PostgreSQL.
**penting**
Kami sangat merekomendasikan untuk menguji sistem jika Anda mengubah faktor isi karena mengubah nilai ini dapat berdampak negatif pada performa, tergantung pada beban kerja Anda.
### Meningkatkan bandwidth jaringan
Untuk melihat apakah terdapat peningkatan latensi tulis, periksa metrik `WriteLatency` di CloudWatch. Jika ada, gunakan metrik `WriteThroughput` dan `ReadThroughput` Amazon CloudWatch untuk memantau lalu lintas terkait penyimpanan pada klaster DB. Metrik ini dapat membantu Anda menentukan apakah bandwidth jaringan cukup untuk aktivitas penyimpanan beban kerja Anda.
Jika tidak cukup, tingkatkan bandwidth jaringan Anda. Jika instans DB Anda mencapai batas bandwidth jaringan, satu-satunya cara untuk meningkatkan bandwidth adalah meningkatkan ukuran instans DB Anda.
Untuk informasi selengkapnya tentang melihat metrik CloudWatch, lihat [CloudWatch Metrik Amazon untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Untuk informasi tentang performa jaringan untuk setiap kelas instans DB, lihat [Spesifikasi perangkat keras untuk kelas instans DB untuk Aurora](Concepts.DBInstanceClass.Summary.md).
# Lock:Relation
Peristiwa `Lock:Relation` terjadi saat kueri menunggu untuk memperoleh kunci pada tabel atau tampilan (relasi) yang saat ini dikunci oleh transaksi lain.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.lockrelation.context.supported)
+ [Konteks](#apg-waits.lockrelation.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.lockrelation.causes)
+ [Tindakan](#apg-waits.lockrelation.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
Sebagian besar perintah PostgreSQL secara implisit menggunakan kunci untuk mengontrol akses konkuren ke data dalam tabel. Anda juga dapat menggunakan kunci ini secara eksplisit dalam kode aplikasi Anda dengan perintah `LOCK`. Banyak mode kunci yang tidak kompatibel satu sama lain, dan mode ini dapat memblokir transaksi saat mencoba mengakses objek yang sama. Apabila hal ini terjadi, Aurora PostgreSQL membuat peristiwa `Lock:Relation`. Berikut adalah beberapa contoh umum:
+ Kunci eksklusif seperti `ACCESS EXCLUSIVE` dapat memblokir semua akses konkuren. Operasi bahasa definisi data (DDL) seperti `DROP TABLE`, `TRUNCATE`, `VACUUM FULL`, dan `CLUSTER` memperoleh kunci `ACCESS EXCLUSIVE` secara implisit. `ACCESS EXCLUSIVE` juga merupakan mode kunci default untuk pernyataan `LOCK TABLE` yang tidak menentukan mode secara eksplisit.
+ Menggunakan `CREATE INDEX (without CONCURRENT)` pada tabel akan bertentangan dengan pernyataan bahasa manipulasi data (DML) `UPDATE`, `DELETE`, dan `INSERT`, yang memperoleh kunci `ROW EXCLUSIVE`.
Untuk informasi selengkapnya tentang kunci tingkat tabel dan mode kunci yang bertentangan, lihat [Explicit Locking](https://www.postgresql.org/docs/13/explicit-locking.html) dalam dokumentasi PostgreSQL.
Kueri dan transaksi yang memblokir biasanya dapat dibuka blokirnya dengan salah satu cara berikut:
+ Kueri yang memblokir – Aplikasi dapat membatalkan kueri atau pengguna dapat mengakhiri proses. Mesin juga dapat memaksa kueri untuk berakhir karena batas waktu pernyataan sesi atau mekanisme deteksi deadlock.
+ Transaksi yang memblokir – Transaksi berhenti memblokir saat menjalankan pernyataan `ROLLBACK` atau `COMMIT`. Rollback juga terjadi secara otomatis saat sesi diputus oleh klien atau masalah jaringan, atau diakhiri. Sesi dapat berakhir saat mesin basis data dimatikan, sistem kehabisan memori, dan sebagainya.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `Lock:Relation` terjadi lebih sering dari biasanya, hal tersebut dapat menunjukkan masalah performa. Penyebab umumnya meliputi yang berikut:
**Peningkatan sesi konkuren dengan kunci tabel yang bertentangan**
Mungkin ada peningkatan jumlah sesi konkuren dengan kueri yang mengunci tabel yang sama dengan mode kunci yang bertentangan.
**Operasi pemeliharaan**
Operasi pemeliharaan kondisi seperti `VACUUM` dan `ANALYZE` dapat secara signifikan meningkatkan jumlah kunci yang bertentangan. `VACUUM FULL` memperoleh kunci `ACCESS EXCLUSIVE`, dan `ANALYZE` memperoleh kunci `SHARE UPDATE EXCLUSIVE`. Kedua jenis kunci tersebut dapat menyebabkan peristiwa tunggu `Lock:Relation`. Operasi pemeliharaan data aplikasi seperti menyegarkan tampilan terwujud juga dapat meningkatkan kueri dan transaksi yang diblokir.
**Kunci pada instans pembaca**
Mungkin ada pertentangan antara kunci relasi yang dipegang oleh penulis dan pembaca. Saat ini, hanya kunci relasi `ACCESS EXCLUSIVE` yang direplikasi ke instans pembaca. Namun, kunci relasi `ACCESS EXCLUSIVE` akan bertentangan dengan kunci relasi `ACCESS SHARE` yang dipegang oleh pembaca. Hal ini dapat menyebabkan peningkatan peristiwa tunggu relasi kunci pada pembaca.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Kurangi dampak pemblokiran pernyataan SQL](#apg-waits.lockrelation.actions.reduce-blocks)
+ [Minimalkan efek operasi pemeliharaan](#apg-waits.lockrelation.actions.maintenance)
+ [Periksa kunci pembaca](#apg-waits.lockrelation.actions.readerlocks)
### Kurangi dampak pemblokiran pernyataan SQL
Untuk mengurangi dampak pemblokiran pernyataan SQL, ubah kode aplikasi Anda jika memungkinkan. Berikut adalah dua teknik umum untuk mengurangi pemblokiran:
+ Gunakan opsi `NOWAIT` – Beberapa perintah SQL, seperti pernyataan `SELECT` dan `LOCK`, mendukung opsi ini. Arahan `NOWAIT` membatalkan kueri permintaan kunci jika kunci tidak dapat segera diperoleh. Teknik ini dapat membantu mencegah sesi yang memblokir menyebabkan penumpukan sesi yang diblokir di belakangnya.
Misalnya: Transaksi A sedang menunggu kunci yang dipegang oleh transaksi B. Jika B meminta kunci pada tabel yang dikunci oleh transaksi C, transaksi A mungkin diblokir hingga transaksi C selesai. Namun, jika transaksi B menggunakan `NOWAIT` saat meminta kunci pada C, transaksi ini dapat gagal cepat (fail fast) dan memastikan bahwa transaksi A tidak harus menunggu tanpa batas waktu.
+ Gunakan `SET lock_timeout` – Tetapkan nilai `lock_timeout` untuk membatasi waktu tunggu pernyataan SQL dalam memperoleh kunci pada relasi. Jika kunci tidak diperoleh dalam batas waktu yang ditentukan, transaksi yang meminta kunci dibatalkan. Tetapkan nilai ini pada tingkat sesi.
### Minimalkan efek operasi pemeliharaan
Operasi pemeliharaan seperti `VACUUM` dan `ANALYZE` bersifat penting. Sebaiknya jangan dinonaktifkan karena peristiwa tunggu `Lock:Relation` berkaitan dengan operasi pemeliharaan ini. Pendekatan berikut dapat meminimalkan efek operasi ini:
+ Jalankan operasi pemeliharaan secara manual di luar jam sibuk.
+ Untuk mengurangi peristiwa tunggu `Lock:Relation` yang disebabkan oleh tugas autovacuum, lakukan penyetelan autovacuum yang diperlukan. Untuk informasi tentang menyetel autovacuum, lihat [Bekerja dengan autovacuum PostgreSQL di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) pada *Panduan Pengguna Amazon RDS*.
### Periksa kunci pembaca
Anda dapat melihat bagaimana sesi bersamaan pada kunci yang mungkin dipegang oleh penulis dan pembaca yang memblokir satu sama lain. Salah satu cara untuk melakukannya adalah dengan menjalankan kueri yang mengembalikan jenis kunci dan relasi. Dalam tabel, Anda dapat menemukan urutan kueri untuk dua sesi bersamaan seperti itu, sesi penulis dan sesi pembaca.
Proses pemutaran ulang menunggu durasi `max_standby_streaming_delay` sebelum membatalkan kueri pembaca. Seperti yang ditunjukkan pada contoh, batas waktu kunci 100 md jauh di bawah default `max_standby_streaming_delay` 30 detik. Waktu kunci habis sebelum menjadi masalah.
| Acara urutan | Sesi | Perintah atau Output |
| --- | --- | --- |
| Menetapkan variabel lingkungan yang disebut READER dengan nilai yang ditentukan dan mencoba untuk terhubung ke instance DB dengan endpoint ini. | Sesi pembaca | Perintah CLI: export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com
psql -h $READER
Output:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Menetapkan variabel lingkungan yang disebut WRITER dan mencoba untuk terhubung ke instance DB dengan endpoint ini. | Sesi penulis | Perintah CLI: export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER
Output:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Sesi penulis membuat tabel t1 pada instance penulis. | Sesi penulis | Kueri PostgreSQL: postgres=> CREATE TABLE t1(b integer);
CREATE TABLE
|
| Jika tidak ada pertanyaan yang bertentangan pada penulis, kunci ACCESS EXCLUSIVE diperoleh pada penulis segera. | Sesi penulis | `ACCESS EXCLUSIVE`kunci diaktifkan |
| Sesi pembaca menetapkan interval batas waktu kunci 100 milidetik. | Sesi pembaca | Kueri PostgreSQL: postgres=> SET lock_timeout=100;
SET
|
| Sesi pembaca mencoba membaca data dari tabel t1 pada instance pembaca. | Sesi pembaca | Kueri PostgreSQL: postgres=> SELECT * FROM t1;
Contoh output:
```
b
---
(0 rows)
``` |
| Sesi penulis turun t1. | Sesi penulis | Kueri PostgreSQL: postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>
|
| Waktu kueri habis dan dibatalkan pada pembaca. | Sesi pembaca | Kueri PostgreSQL: postgres=> SELECT * FROM t1;
Contoh output:
```
ERROR: canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
^
``` |
| Untuk menentukan penyebab kesalahan. kueri sesi pembaca dan `pg_locks` `pg_stat_activity` | Sesi pembaca | Kueri PostgreSQL: postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;
|
| Hasilnya menunjukkan bahwa `aurora wal replay` proses memegang `ACCESS EXCLUSIVE` kunci pada tabel t1. | Sesi pembaca | Hasil kueri: locktype | relation | mode | backend_type
----------+----------+---------------------+-------------------
relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)
|
# Lock:transactionid
Peristiwa `Lock:transactionid` terjadi saat transaksi sedang menunggu kunci tingkat baris.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.locktransactionid.context.supported)
+ [Konteks](#apg-waits.locktransactionid.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.locktransactionid.causes)
+ [Tindakan](#apg-waits.locktransactionid.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
Peristiwa `Lock:transactionid` terjadi saat transaksi mencoba memperoleh kunci tingkat baris yang telah diberikan untuk transaksi yang sedang berlangsung pada saat bersamaan. Sesi yang menunjukkan peristiwa tunggu `Lock:transactionid` diblokir karena kunci ini. Setelah transaksi pemblokiran berakhir dengan pernyataan `COMMIT` atau `ROLLBACK`, transaksi yang diblokir dapat dilanjutkan.
Semantik kontrol bersamaan multiversi dari Aurora PostgreSQL menjamin bahwa pembaca tidak memblokir penulis dan penulis tidak memblokir pembaca. Agar pertentangan tingkat baris terjadi, transaksi yang memblokir dan diblokir harus mengeluarkan pernyataan yang bertentangan dari jenis berikut:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
Pernyataan `SELECT … FOR KEY SHARE` adalah kasus khusus. Basis data menggunakan klausa `FOR KEY SHARE` untuk mengoptimalkan performa integritas referensial. Kunci tingkat baris pada baris dapat memblokintah `INSERT`, `UPDATE`, dan `DELETE` pada tabel lain yang mereferensikan baris tersebut.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa ini ditampilkan lebih dari biasanya, penyebabnya biasanya adalah pernyataan `UPDATE`, `SELECT … FOR UPDATE`, atau `SELECT … FOR KEY SHARE` yang dikombinasikan dengan kondisi berikut.
**Topics**
+ [Konkurensi tinggi](#apg-waits.locktransactionid.concurrency)
+ [Idle pada transaksi](#apg-waits.locktransactionid.idle)
+ [Transaksi yang berjalan lama](#apg-waits.locktransactionid.long-running)
### Konkurensi tinggi
Aurora PostgreSQL dapat menggunakan semantik penguncian tingkat baris terperinci. Probabilitas pertentangan tingkat baris meningkat saat kondisi berikut terpenuhi:
+ Beberapa beban kerja yang sangat konkuren bersaing untuk baris yang sama.
+ Konkurensi meningkat.
### Idle pada transaksi
Terkadang kolom `pg_stat_activity.state` menunjukkan nilai `idle in transaction`. Nilai ini ditampilkan untuk sesi yang telah memulai transaksi, tetapi belum mengeluarkan `COMMIT` atau `ROLLBACK`. Jika nilai `pg_stat_activity.state` bukan `active`, kueri yang ditampilkan pada `pg_stat_activity` adalah yang paling baru diselesaikan. Sesi yang memblokir tidak secara aktif memproses kueri karena transaksi yang terbuka menahan kunci.
Jika transaksi yang idle memperoleh kunci tingkat baris, transaksi tersebut mungkin mencegah sesi lain memperolehnya. Kondisi ini menyebabkan peristiwa tunggu `Lock:transactionid` sering terjadi. Untuk mendiagnosis masalah, periksa output dari `pg_stat_activity` dan `pg_locks`.
### Transaksi yang berjalan lama
Transaksi yang berjalan dalam waktu lama akan mendapatkan kunci untuk waktu lama. Kunci yang lama dipegang ini dapat memblokir transaksi lain sehingga tidak berjalan.
## Tindakan
Penguncian baris adalah pertentangan antara pernyataan `UPDATE`, `SELECT … FOR UPDATE`, atau `SELECT … FOR KEY SHARE`. Sebelum mencoba solusi, cari tahu kapan pernyataan ini berjalan pada baris yang sama. Gunakan informasi ini untuk memilih strategi yang dijelaskan pada bagian berikut.
**Topics**
+ [Tangani konkurensi tinggi](#apg-waits.locktransactionid.actions.problem)
+ [Tangani transaksi idle](#apg-waits.locktransactionid.actions.find-blocker)
+ [Tangani transaksi yang berjalan lama](#apg-waits.locktransactionid.actions.concurrency)
### Tangani konkurensi tinggi
Jika masalahnya adalah konkurensi, coba salah satu teknik berikut:
+ Turunkan konkurensi pada aplikasi. Misalnya, kurangi jumlah sesi aktif.
+ Terapkan pool koneksi. Untuk mempelajari cara melakukan pooling koneksi dengan Proksi RDS, lihat [Proksi Amazon RDS untuk Aurora](rds-proxy.md).
+ Desain aplikasi atau model data untuk menghindari pertentangan pernyataan `UPDATE` dan `SELECT … FOR UPDATE`. Anda juga dapat mengurangi jumlah kunci asing yang diakses oleh pernyataan `SELECT … FOR KEY SHARE`.
### Tangani transaksi idle
Jika `pg_stat_activity.state` menampilkan `idle in transaction`, gunakan strategi berikut:
+ Aktifkan autocommit saat memungkinkan. Pendekatan ini mencegah transaksi memblokir transaksi lain sambil menunggu `COMMIT` atau `ROLLBACK`.
+ Cari jalur kode yang tidak memiliki `COMMIT`, `ROLLBACK`, atau `END`.
+ Pastikan logika penanganan pengecualian pada aplikasi Anda selalu memiliki jalur ke `end of transaction` yang valid.
+ Pastikan bahwa aplikasi Anda memproses hasil kueri setelah mengakhiri transaksi dengan `COMMIT` atau `ROLLBACK`.
### Tangani transaksi yang berjalan lama
Jika transaksi yang berjalan lama menyebabkan `Lock:transactionid` sering terjadi, coba strategi berikut:
+ Cegah kunci baris dari transaksi jangka panjang.
+ Batasi panjang kueri dengan menerapkan autocommit jika memungkinkan.
# Lock:tuple
Peristiwa `Lock:tuple` terjadi saat proses backend menunggu perolehan kunci pada tuple.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.locktuple.context.supported)
+ [Konteks](#apg-waits.locktuple.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.locktuple.causes)
+ [Tindakan](#apg-waits.locktuple.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
Peristiwa `Lock:tuple` menunjukkan bahwa backend sedang menunggu untuk memperoleh kunci pada tuple, sementara backend lain memegang kunci yang bertentangan pada tuple yang sama. Tabel berikut menggambarkan skenario saat sesi membuat peristiwa `Lock:tuple`.
| Waktu | Sesi 1 | Sesi 2 | Sesi 3 |
| --- | --- | --- | --- |
| t1 | Memulai transaksi. | | |
| t2 | Memperbarui baris 1. | | |
| t3 | | Memperbarui baris 1. Sesi tersebut mendapatkan kunci eksklusif pada tuple, lalu menunggu sesi 1 untuk melepaskan kunci dengan metode commit atau rollback. | |
| t4 | | | Memperbarui baris 1. Sesi tersebut menunggu sesi 2 untuk melepaskan kunci eksklusif pada tuple. |
Atau Anda dapat menyimulasikan peristiwa tunggu ini dengan menggunakan alat benchmarking `pgbench`. Konfigurasikan jumlah sesi bersamaan yang tinggi untuk memperbarui baris yang sama pada tabel dengan file SQL khusus.
Untuk mempelajari selengkapnya tentang mode kunci yang bertentangan, lihat [Penguncian Eksplisit](https://www.postgresql.org/docs/current/explicit-locking.html) pada dokumentasi PostgreSQL. Untuk mempelajari selengkapnya tentang `pgbench`, lihat [pgbench](https://www.postgresql.org/docs/current/pgbench.html) pada dokumentasi PostgreSQL.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa ini ditampilkan lebih dari biasanya, mungkin menunjukkan masalah performa, penyebab umumnya terdiri dari berikut:
+ Sesi bersamaan dalam jumlah yang tinggi mencoba mendapatkan kunci yang bertentangan untuk tuple yang sama dengan menjalankan pernyataan `UPDATE` atau `DELETE`.
+ Sesi bersamaan yang tinggi menjalankan pernyataan `SELECT` menggunakan mode kunci `FOR UPDATE` atau `FOR NO KEY UPDATE`.
+ Berbagai faktor mendorong aplikasi atau pool koneksi untuk membuka lebih banyak sesi agar menjalankan operasi yang sama. Saat sesi baru mencoba memodifikasi baris yang sama, beban DB dapat melonjak, dan `Lock:tuple` dapat ditampilkan.
Untuk informasi selengkapnya, lihat [Penguncian Tingkat Baris](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) pada dokumentasi PostgreSQL.
## Tindakan
Kami merekomendasikan berbagai tindakan tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Menyelidiki logika aplikasi](#apg-waits.locktuple.actions.problem)
+ [Menemukan sesi pemblokir](#apg-waits.locktuple.actions.find-blocker)
+ [Mengurangi konkurensi saat tinggi](#apg-waits.locktuple.actions.concurrency)
+ [Memecahkan masalah](#apg-waits.locktuple.actions.bottlenecks)
### Menyelidiki logika aplikasi
Cari tahu apakah sesi pemblokir telah berada pada status `idle in transaction` dalam waktu yang lama. Jika demikian, coba akhiri sesi pemblokir sebagai solusi jangka pendek. Anda dapat menggunakan fungsi `pg_terminate_backend`. Untuk informasi selengkapnya tentang fungsi ini, lihat [Fungsi Pemberi Sinyal Server](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) pada dokumentasi PostgreSQL.
Untuk solusi jangka panjang, lakukan hal berikut:
+ Sesuaikan logika aplikasi.
+ Gunakan parameter `idle_in_transaction_session_timeout`. Parameter ini mengakhiri sesi apa pun dengan transaksi terbuka yang telah idle lebih lama dari jumlah waktu yang ditentukan. Untuk informasi selengkapnya, lihat [Default Koneksi Klien](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) pada dokumentasi PostgreSQL.
+ Gunakan autocommit sebanyak mungkin. Untuk informasi selengkapnya, lihat [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) pada dokumentasi PostgreSQL.
### Menemukan sesi pemblokir
Saat peristiwa tunggu `Lock:tuple` terjadi, identifikasi pemblokir dan sesi yang diblokir dengan mencari tahu kunci yang bergantung satu sama lain. Untuk informasi selengkapnya, lihat [Informasi dependensi kunci](https://wiki.postgresql.org/wiki/Lock_dependency_information) pada wiki PostgreSQL. Untuk menganalisis peristiwa `Lock:tuple` yang lampau, gunakan fungsi Aurora `aurora_stat_backend_waits`.
Contoh berikut memberikan kueri semua sesi, memfilter `tuple`, dan mengurutkan berdasarkan `wait_time`.
```
--AURORA_STAT_BACKEND_WAITS
SELECT a.pid,
a.usename,
a.app_name,
a.current_query,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
left(query,80) as current_query,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND usename<>'rdsadmin') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we
WHERE we.event_name = 'tuple'
ORDER BY a.wait_time;
pid | usename | app_name | current_query | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+---------+----------+------------------------------------------------+-------------------+--------------------+---------------+-----------+------------+-------+-----------
32136 | sys | psql | /*session3*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000018
11999 | sys | psql | /*session4*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000024
```
### Mengurangi konkurensi saat tinggi
Peristiwa `Lock:tuple` mungkin terjadi terus-menerus, terutama pada waktu beban kerja yang sibuk. Dalam situasi ini, coba kurangi konkurensi tinggi untuk baris yang sangat sibuk. Sering kali, hanya beberapa baris mengontrol antrean atau logika Boolean, yang membuat baris ini sangat sibuk.
Anda dapat mengurangi konkurensi dengan menggunakan pendekatan yang berbeda berdasarkan ketentuan bisnis, logika aplikasi, dan jenis beban kerja. Misalnya, Anda dapat melakukan hal berikut:
+ Mendesain ulang tabel dan logika data untuk mengurangi konkurensi tinggi.
+ Mengubah logika aplikasi untuk mengurangi konkurensi tinggi di tingkat baris.
+ Memanfaatkan dan mendesain ulang kueri dengan kunci tingkat baris.
+ Menggunakan klausa `NOWAIT` dengan operasi coba lagi.
+ Mempertimbangkan penggunaan kontrol konkurensi logika penguncian hibrid yang optimis.
+ Mempertimbangkan perubahan tingkat isolasi basis data.
### Memecahkan masalah
`Lock:tuple` dapat terjadi dengan masalah seperti kekurangan CPU atau penggunaan maksimum bandwidth Amazon EBS. Untuk mengurangi masalah, pertimbangkan pendekatan berikut:
+ Menaikkan skala jenis kelas instans.
+ Mengoptimalkan kueri intensif sumber daya.
+ Mengubah logika aplikasi.
+ Mengarsipkan data yang jarang diakses.
# LWLock:buffer\$1content () 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`.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.lockbuffercontent.context.supported)
+ [Konteks](#apg-waits.lockbuffercontent.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.lockbuffercontent.causes)
+ [Tindakan](#apg-waits.lockbuffercontent.actions)
## 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`.
**Topics**
+ [Meningkatkan efisiensi dalam memori](#apg-waits.lockbuffercontent.actions.in-memory)
+ [Kurangi penggunaan batasan kunci asing](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [Hapus indeks yang tidak digunakan](#apg-waits.lockbuffercontent.actions.indexes)
+ [Hapus indeks duplikat](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [Drop atau REINDEX indeks tidak valid](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [Gunakan indeks sebagian](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [Hapus tabel dan indeks kembung](#apg-waits.lockbuffercontent.actions.bloat)
### 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](Concepts.DBInstanceClass.md).
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](https://github.com/awslabs/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](https://github.com/awslabs/pg-collector) 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](https://github.com/awslabs/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](https://github.com/awslabs/pg-collector) 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](https://www.postgresql.org/docs/current/indexes-partial.html), 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](AuroraPostgreSQL.diag-table-ind-bloat.md) Selanjutnya, bagian Fragmentation (Bloat) dari laporan [PG Collector](https://github.com/awslabs/pg-collector) dapat memberikan wawasan tentang tabel dan indeks yang membengkak.
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\$1repack**
`pg_repack`Ini 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 menggunakan`pg_repack`, lihat [Menghapus bloat dengan pg\$1repack dan pg\$1repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html).](https://reorg.github.io/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 tentang [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html)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 [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html).
# LWLock:buffer\$1pemetaan
Peristiwa ini terjadi saat sesi menunggu untuk mengaitkan blok data dengan buffer di pool buffer bersama.
**catatan**
Peristiwa ini ditampilkan sebagai `LWLock:buffer_mapping` di Aurora PostgreSQL versi 12 dan yang lebih rendah, serta `LWLock:BufferMapping` di versi 13 dan yang lebih tinggi.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Konteks](#apg-waits.lwl-buffer-mapping.context)
+ [Penyebab](#apg-waits.lwl-buffer-mapping.causes)
+ [Tindakan](#apg-waits.lwl-buffer-mapping.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini relevan untuk Aurora PostgreSQL versi 9.6 dan yang lebih tinggi.
## Konteks
*Pool buffer bersama* adalah area memori Aurora PostgreSQL yang memegang semua halaman yang sedang atau telah digunakan oleh proses. Saat memerlukan halaman, suatu proses membaca halaman ke dalam pool buffer bersama. Parameter `shared_buffers` menetapkan ukuran buffer bersama dan menyimpan area memori untuk menyimpan tabel dan halaman indeks. Jika Anda mengubah parameter ini, pastikan untuk memulai ulang basis data. Untuk informasi selengkapnya, lihat [Buffer bersama](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).
Peristiwa tunggu `LWLock:buffer_mapping` terjadi dalam skenario berikut:
+ Sebuah proses mencari tabel buffer untuk halaman dan memperoleh kunci pemetaan buffer bersama.
+ Sebuah proses memuat halaman ke dalam pool buffer dan memperoleh kunci pemetaan buffer eksklusif.
+ Sebuah proses menghapus halaman dari pool dan memperoleh kunci pemetaan buffer eksklusif.
## Penyebab
Ketika peristiwa ini muncul lebih sering dari biasanya, yang mungkin menunjukkan masalah performa, basis data akan melakukan paging masuk dan keluar pada pool buffer bersama. Penyebab umumnya meliputi yang berikut:
+ Kueri besar
+ Indeks dan tabel yang mengalami bloat
+ Pemindaian tabel lengkap
+ Ukuran pool bersama yang lebih kecil dari working set
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Pantau metrik terkait buffer](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Evaluasi strategi pengindeksan Anda](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Kurangi jumlah buffer yang harus dialokasikan dengan cepat](#apg-waits.lwl-buffer-mapping.actions.buffers)
### Pantau metrik terkait buffer
Saat `LWLock:buffer_mapping` menunggu lonjakan, selidiki rasio hit buffer. Anda dapat menggunakan metrik ini untuk mendapatkan pemahaman yang lebih baik tentang apa yang terjadi di cache buffer. Periksa metrik berikut:
`BufferCacheHitRatio`
CloudWatch Metrik Amazon ini mengukur persentase permintaan yang disajikan oleh cache buffer instans DB di cluster DB Anda. Anda mungkin melihat penurunan metrik ini sebelum peristiwa tunggu `LWLock:buffer_mapping`.
`blks_hit`
Metrik penghitung Wawasan Performa ini menunjukkan jumlah blok yang diambil dari pool buffer bersama. Setelah peristiwa tunggu `LWLock:buffer_mapping` muncul, Anda mungkin melihat lonjakan `blks_hit`.
`blks_read`
Metrik penghitung Performance Insights ini menunjukkan jumlah blok yang perlu dibaca I/O ke dalam kumpulan buffer bersama. Anda mungkin melihat lonjakan `blks_read` menjelang peristiwa tunggu `LWLock:buffer_mapping`.
### Evaluasi strategi pengindeksan Anda
Untuk mengonfirmasi bahwa strategi pengindeksan Anda tidak menurunkan performa, periksa hal berikut:
Bloat indeks
Pastikan bloat indeks dan tabel tidak menyebabkan halaman yang tidak perlu dibacakan ke buffer bersama. Jika tabel Anda berisi baris yang tidak digunakan, pertimbangkan untuk mengarsipkan datanya dan menghapus baris tersebut dari tabel. Anda kemudian dapat membuat kembali indeks untuk tabel yang diubah ukurannya.
Indeks untuk kueri yang sering digunakan
Untuk menentukan apakah Anda memiliki indeks optimal, pantau metrik mesin DB di Wawasan Performa. Metrik `tup_returned` menunjukkan jumlah baris yang dibaca. Metrik `tup_fetched` menunjukkan jumlah baris yang dikembalikan ke klien. Jika `tup_returned` secara signifikan lebih besar dari `tup_fetched`, data mungkin tidak diindeks dengan benar. Selain itu, statistik tabel Anda mungkin tidak terkini.
### Kurangi jumlah buffer yang harus dialokasikan dengan cepat
Untuk mengurangi peristiwa tunggu `LWLock:buffer_mapping`, coba kurangi jumlah buffer yang harus dialokasikan dengan cepat. Salah satu strateginya adalah dengan melakukan operasi batch yang lebih kecil. Anda mungkin dapat memiliki batch yang lebih kecil dengan mempartisi tabel Anda.
# LWLock:BufferIO (IPC: Bufferio)
`LWLock:BufferIO`Peristiwa ini terjadi ketika Aurora PostgreSQL atau RDS untuk PostgreSQL sedang menunggu proses lain untuk menyelesaikan operasi mereka) ketika secara bersamaan mencoba mengakses halaman. input/output (I/O Tujuannya adalah agar halaman yang sama dibacakan ke buffer bersama.
**Topics**
+ [Versi mesin yang relevan](#apg-waits.lwlockbufferio.context.supported)
+ [Konteks](#apg-waits.lwlockbufferio.context)
+ [Penyebab](#apg-waits.lwlockbufferio.causes)
+ [Tindakan](#apg-waits.lwlockbufferio.actions)
## Versi mesin yang relevan
Informasi peristiwa tunggu ini relevan untuk semua versi Aurora PostgreSQL. Untuk Aurora PostgreSQL 12 dan versi sebelumnya, peristiwa tunggu ini disebut lwlock:buffer\$1io, sedangkan pada Aurora PostgreSQL versi 13 disebut lwlock:bufferio. Dari Aurora PostgreSQL versi 14, peristiwa tunggu BufferIO dipindahkan dari jenis peristiwa tunggu `LWLock` ke `IPC` (IPC:BufferIO).
## Konteks
Setiap buffer bersama memiliki kunci I/O yang terkait dengan peristiwa tunggu `LWLock:BufferIO`, setiap kali blok (atau halaman) harus diambil di luar pool buffer bersama.
Kunci ini digunakan untuk menangani beberapa sesi yang semuanya memerlukan akses ke blok yang sama. Blok ini harus dibaca dari luar pool buffer bersama, yang ditentukan oleh parameter `shared_buffers`.
Segera setelah halaman dibaca di dalam kumpulan buffer bersama, kunci `LWLock:BufferIO` akan dilepaskan.
**catatan**
Peristiwa tunggu `LWLock:BufferIO` mendahului peristiwa tunggu [IO: DataFileRead](apg-waits.iodatafileread.md). Peristiwa tunggu `IO:DataFileRead` terjadi saat data sedang dibaca dari penyimpanan.
Untuk informasi selengkapnya tentang kunci ringan, lihat [Gambaran Umum Penguncian](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Penyebab
Penyebab umum peristiwa `LWLock:BufferIO` muncul dalam peristiwa tunggu teratas mencakup yang berikut:
+ Beberapa backend atau koneksi mencoba mengakses halaman yang sama yang juga menunggu operasi I/O
+ Rasio antara ukuran pool buffer bersama (ditentukan oleh parameter `shared_buffers`) dan jumlah buffer yang dibutuhkan oleh beban kerja saat ini
+ Ukuran pool buffer bersama tidak seimbang dengan jumlah halaman yang dikosongkan oleh operasi lain
+ Indeks besar atau bloat yang mengharuskan mesin membacakan lebih banyak halaman daripada yang diperlukan ke dalam pool buffer bersama
+ Kurangnya indeks yang memaksa mesin DB untuk membaca lebih banyak halaman dari tabel daripada yang diperlukan
+ Lonjakan mendadak untuk koneksi basis data yang mencoba melakukan operasi pada halaman yang sama
## Tindakan
Kami merekomendasikan berbagai tindakan tergantung pada penyebab peristiwa tunggu Anda:
+ Amati CloudWatch metrik Amazon untuk korelasi antara penurunan tajam dalam peristiwa `BufferCacheHitRatio` dan `LWLock:BufferIO` menunggu. Efek ini dapat berarti bahwa Anda memiliki pengaturan buffer bersama kecil. Anda mungkin perlu meningkatkan atau menaikkan skala kelas instans DB Anda. Anda dapat membagi beban kerja Anda menjadi lebih banyak simpul pembaca.
+ Verifikasi apakah Anda memiliki indeks yang tidak digunakan, lalu hapus.
+ Gunakan tabel yang dipartisi (yang juga memiliki indeks yang dipartisi). Dengan melakukan hal ini, Anda dapat menjaga penyusunan ulang indeks tetap rendah dan mengurangi dampaknya.
+ Hindari kolom pengindeksan yang tidak perlu.
+ Cegah lonjakan koneksi basis data yang tiba-tiba dengan menggunakan pool koneksi.
+ Batasi jumlah maksimum koneksi ke basis data sebagai praktik terbaik.
# 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).
# LWLock:MultiXact
Peristiwa tunggu `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU`, dan `LWLock:MultiXactOffsetSLRU` menunjukkan bahwa sesi sedang menunggu pengambilan daftar transaksi yang memodifikasi baris yang sama pada tabel tertentu.
+ `LWLock:MultiXactMemberBuffer` – Suatu proses sedang menunggu I/O pada buffer simple least-recently used (SLRU) untuk anggota multixact.
+ `LWLock:MultiXactMemberSLRU` – Suatu proses sedang menunggu akses cache simple least-recently used (SLRU) untuk anggota multixact.
+ `LWLock:MultiXactOffsetBuffer` – Suatu proses sedang menunggu I/O pada buffer simple least-recently used (SLRU) untuk offset multixact.
+ `LWLock:MultiXactOffsetSLRU` – Suatu proses sedang menunggu akses cache simple least-recently used (SLRU) untuk offset multixact.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.xactsync.context.supported)
+ [Konteks](#apg-waits.lwlockmultixact.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.lwlockmultixact.causes)
+ [Tindakan](#apg-waits.lwlockmultixact.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
*Multixact* adalah struktur data yang menyimpan daftar transaksi IDs (XIDs) yang memodifikasi baris tabel yang sama. Saat satu transaksi merujuk suatu baris dalam tabel, ID transaksi disimpan pada baris header tabel. Ketika beberapa transaksi mereferensikan baris yang sama dalam tabel, daftar transaksi IDs disimpan dalam struktur data multixact. Peristiwa tunggu multixact menunjukkan bahwa sesi mengambil dari struktur data daftar transaksi yang merujuk ke baris tertentu dalam tabel.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Tiga penyebab umum penggunaan multixact adalah sebagai berikut:
+ **Subtransaksi dari titik simpan eksplisit** – Secara eksplisit membuat titik simpan pada transaksi Anda yang memunculkan transaksi baru untuk baris yang sama. Misalnya, menggunakan `SELECT FOR UPDATE`, lalu `SAVEPOINT`, dan `UPDATE`.
Beberapa driver, pemetaan relasional objek (ORMs), dan lapisan abstraksi memiliki opsi konfigurasi untuk secara otomatis membungkus semua operasi dengan savepoint. Hal ini dapat membuat banyak peristiwa tunggu multixact di beberapa beban kerja. Opsi `autosave` Driver JDBC PostgreSQL adalah contohnya. Untuk informasi selengkapnya, lihat [pgJDBC](https://jdbc.postgresql.org/) pada dokumentasi JDBC PostgreSQL. Contoh lainnya adalah driver ODBC PostgreSQL dan opsi `protocol`. Untuk informasi selengkapnya, lihat [Opsi Konfigurasi psqlODBC](https://odbc.postgresql.org/docs/config.html) pada dokumentasi driver ODBC PostgreSQL.
+ **Subtransaksi dari klausa PL/pgSQL EXCEPTION** – Setiap klausa `EXCEPTION` yang Anda tulis dalam fungsi atau prosedur PL/pgSQL membuat `SAVEPOINT` secara internal.
+ **Kunci asing** – Beberapa transaksi memperoleh kunci bersama pada catatan induk.
Ketika baris tertentu disertakan dalam operasi transaksi ganda, memproses baris memerlukan pengambilan transaksi IDs dari `multixact` daftar. Jika pencarian tidak mendapatkan multixact dari cache memori, struktur data harus dibaca dari lapisan penyimpanan Aurora. I/O dari penyimpanan ini berarti kueri SQL dapat memerlukan waktu lebih lama. Kesalahan cache memori dapat mulai terjadi dengan penggunaan yang berat karena jumlah transaksi ganda yang besar. Semua faktor ini berkontribusi pada peningkatan peristiwa tunggu ini.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Beberapa tindakan ini dapat membantu untuk segera mengurangi peristiwa tunggu. Namun, yang lainnya mungkin memerlukan penyelidikan dan koreksi untuk menskalakan beban kerja Anda.
**Topics**
+ [Lakukan pembekuan vakum di atas tabel dengan peristiwa tunggu ini](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Tingkatkan frekuensi autovacuum pada tabel dengan peristiwa tunggu ini](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Meningkatkan parameter memori](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Mengurangi transaksi jangka panjang](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Tindakan jangka panjang](#apg-waits.lwlockmultixact.actions.longactions)
### Lakukan pembekuan vakum di atas tabel dengan peristiwa tunggu ini
Jika peristiwa tunggu ini melonjak mendadak dan memengaruhi lingkungan produksi, Anda dapat menggunakan salah satu metode sementara berikut untuk mengurangi penghitungannya.
+ Gunakan *VACUUM FREEZE* pada tabel atau partisi tabel yang terpengaruh untuk segera menyelesaikan masalah. Untuk informasi selengkapnya, lihat [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Gunakan klausa VACUUM (FREEZE, INDEX\$1CLEANUP FALSE) untuk melakukan vakum cepat dengan melewati indeks. Untuk informasi selengkapnya, lihat [Memvakum tabel secepat mungkin](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Tingkatkan frekuensi autovacuum pada tabel dengan peristiwa tunggu ini
Setelah memindai semua tabel di semua basis data, VACUUM akan menghapus multixact, dan nilai multixact tertua akan dimajukan. Untuk informasi selengkapnya, lihat [Multixact dan Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). Untuk menjaga LWLock: MultiXact tunggu acara seminimal mungkin, Anda harus menjalankan VACUUM sesering yang diperlukan. Untuk melakukannya, pastikan bahwa VACUUM di klaster DB Aurora PostgreSQL Anda dikonfigurasi secara optimal.
Jika menggunakan VACUUM FREEZE pada tabel atau partisi tabel yang terpengaruh menyelesaikan masalah peristiwa tunggu, sebaiknya gunakan penjadwal, seperti `pg_cron`, untuk melakukan VACUUM daripada menyesuaikan autovacuum pada tingkat instans.
Agar autovacuum terjadi lebih sering, Anda dapat mengurangi nilai parameter penyimpanan `autovacuum_multixact_freeze_max_age` pada tabel yang terpengaruh. Untuk informasi selengkapnya, lihat [autovacuum\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Meningkatkan parameter memori
Anda dapat mengoptimalkan penggunaan memori untuk cache multixact dengan menyesuaikan parameter berikut. Pengaturan ini mengontrol berapa banyak memori yang disediakan untuk cache ini, yang dapat membantu mengurangi peristiwa menunggu multixact di beban kerja Anda. Kami merekomendasikan memulai dengan nilai-nilai berikut:
Untuk Aurora PostgreSQL 17 dan yang lebih baru:
+ `multixact_offset_buffers`= 128
+ `multixact_member_buffers`= 256
Untuk Aurora PostgreSQL 16 dan sebelumnya:
+ `multixact_offsets_cache_size`= 128
+ `multixact_members_cache_size`= 256
**catatan**
Di Aurora PostgreSQL 17, nama parameter diubah dari `multixact_offsets_cache_size` ke `multixact_offset_buffers` dan dari menjadi selaras dengan komunitas PostgreSQL 17. `multixact_members_cache_size` `multixact_member_buffers`
Anda dapat mengatur parameter ini di tingkat cluster sehingga semua instance di cluster Anda tetap konsisten. Kami menyarankan Anda untuk menguji dan menyesuaikan nilai agar sesuai dengan persyaratan beban kerja spesifik dan kelas instance Anda. Anda harus me-reboot instance writer agar perubahan parameter diterapkan.
Parameter dinyatakan dalam hal entri cache multixact. Setiap entri cache menggunakan `8 KB` memori. Untuk menghitung total memori yang dicadangkan, kalikan setiap nilai parameter dengan`8 KB`. Misalnya, jika Anda menyetel parameter ke 128, total memori cadangan akan menjadi`128 * 8 KB = 1 MB`.
### Mengurangi transaksi jangka panjang
Transaksi jangka panjang menyebabkan vakum mempertahankan informasinya hingga transaksi tersebut dilakukan atau hingga transaksi hanya dibaca ditutup. Kami merekomendasikan Anda untuk secara proaktif memantau dan mengelola transaksi jangka panjang. Untuk informasi selengkapnya, lihat [Basis data telah lama berjalan idle dalam koneksi transaksi](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Cobalah untuk memodifikasi aplikasi Anda untuk menghindari atau meminimalkan penggunaan transaksi jangka panjang Anda.
### Tindakan jangka panjang
Periksa beban kerja Anda untuk menemukan penyebab limpahan multixact. Anda harus memperbaiki masalah tersebut untuk menskalakan beban kerja Anda dan mengurangi peristiwa tunggu.
+ Anda harus menganalisis DDL (data definition language) yang digunakan untuk membuat tabel Anda. Pastikan bahwa struktur dan indeks tabel dirancang dengan baik.
+ Saat tabel yang terpengaruh memiliki kunci asing, tentukan apakah diperlukan atau jika ada cara lain untuk memberlakukan integritas referensial.
+ Saat sebuah tabel memiliki indeks besar yang tidak digunakan, hal tersebut dapat menyebabkan autovacuum tidak sesuai dengan beban kerja Anda dan mungkin memblokirnya agar tidak berjalan. Untuk menghindari hal ini, periksa indeks yang tidak digunakan dan hapus sepenuhnya. Untuk informasi selengkapnya, lihat [Mengelola autovacuum dengan indeks besar](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Kurangi penggunaan titik simpan dalam transaksi Anda.
# LWLock:pg\$1stat\$1statement
Peristiwa LWLock tunggu: PG\$1STAT\$1Statements terjadi ketika ekstensi `pg_stat_statements` mengambil kunci eksklusif pada tabel hash yang melacak pernyataan SQL. Ini terjadi dalam skenario berikut:
+ Ketika jumlah pernyataan yang dilacak mencapai nilai `pg_stat_statements.max` parameter yang dikonfigurasi dan ada kebutuhan untuk memberi ruang untuk lebih banyak entri, ekstensi melakukan pengurutan pada jumlah panggilan, menghapus 5% dari pernyataan yang paling tidak dieksekusi, dan mengisi ulang hash dengan entri yang tersisa.
+ Ketika `pg_stat_statements` melakukan `garbage collection` operasi ke `pgss_query_texts.stat` file pada disk dan menulis ulang file.
**Topics**
+ [Versi mesin yang didukung](#apg-rpg-lwlockpgstat.supported)
+ [Konteks](#apg-rpg-lwlockpgstat.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-rpg-lwlockpgstat.causes)
+ [Tindakan](#apg-rpg-lwlockpgstat.actions)
## Versi mesin yang didukung
Informasi acara tunggu ini didukung untuk semua versi .
## Konteks
**Memahami ekstensi pg\$1stat\$1statement - Ekstensi** pg\$1stat\$1statement melacak statistik eksekusi pernyataan SQL dalam tabel hash. Ekstensi melacak pernyataan SQL hingga batas yang ditentukan oleh `pg_stat_statements.max` parameter. Parameter ini menentukan jumlah maksimum pernyataan yang dapat dilacak yang sesuai dengan jumlah maksimum baris dalam tampilan pg\$1stat\$1statement.
**Persistensi statistik pernyataan** — Ekstensi mempertahankan statistik pernyataan di seluruh instans dimulai ulang dengan:
+ Menulis data ke file bernama pg\$1stat\$1statements.stat
+ Menggunakan parameter pg\$1stat\$1statements.save untuk mengontrol perilaku persistensi
Ketika pg\$1stat\$1statements.save diatur ke:
+ aktif (default): Statistik disimpan saat shutdown dan dimuat ulang saat server dimulai
+ off: Statistik tidak disimpan saat shutdown atau dimuat ulang saat server dimulai
**Penyimpanan teks kueri** — Ekstensi menyimpan teks kueri yang dilacak dalam file bernama. `pgss_query_texts.stat` File ini dapat tumbuh menjadi dua kali lipat ukuran rata-rata semua pernyataan SQL yang dilacak sebelum pengumpulan sampah terjadi. Ekstensi memerlukan kunci eksklusif pada tabel hash selama operasi pembersihan dan menulis ulang `pgss_query_texts.stat` file.
**Proses deallocation pernyataan** — Ketika jumlah pernyataan yang dilacak mencapai `pg_stat_statements.max` batas dan pernyataan baru perlu dilacak, ekstensi:
+ Mengambil kunci eksklusif: pg\$1stat\$1statement) LWLock pada tabel hash.
+ Memuat data yang ada ke dalam memori lokal.
+ Melakukan quicksort berdasarkan jumlah panggilan.
+ Menghapus pernyataan yang paling tidak disebut (5% bawah).
+ Mengisi ulang tabel hash dengan entri yang tersisa.
**Monitoring statement deallocation** — Di PostgreSQL 14 dan yang lebih baru, Anda dapat memantau deallocation pernyataan menggunakan tampilan pg\$1stat\$1statements\$1info. Tampilan ini mencakup kolom dealloc yang menunjukkan berapa kali pernyataan dialokasikan untuk memberi ruang bagi yang baru
Jika deallocation pernyataan sering terjadi, itu akan menyebabkan pengumpulan sampah `pgss_query_texts.stat` file yang lebih sering pada disk.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Penyebab khas peningkatan `LWLock:pg_stat_statements` menunggu meliputi:
+ Peningkatan jumlah kueri unik yang digunakan oleh aplikasi.
+ Nilai `pg_stat_statements.max` parameter menjadi kecil dibandingkan dengan jumlah query unik yang digunakan.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Anda dapat mengidentifikasi `LWLock:pg_stat_statements` peristiwa dengan menggunakan Amazon RDS Performance Insights atau dengan menanyakan tampilan. `pg_stat_activity`
Sesuaikan `pg_stat_statements` parameter berikut untuk mengontrol perilaku pelacakan dan kurangi: LWLock pg\$1stat\$1 statement wait events.
**Topics**
+ [Nonaktifkan parameter pg\$1stat\$1statements.track](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Meningkatkan parameter pg\$1stat\$1statements.max](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Nonaktifkan parameter pg\$1stat\$1statements.track\$1utility](#apg-rpg-lwlockpgstat.actions.disableutility)
### Nonaktifkan parameter pg\$1stat\$1statements.track
Jika peristiwa:pg\$1stat\$1statement LWLock wait berdampak buruk pada kinerja database, dan solusi cepat diperlukan sebelum analisis lebih lanjut dari tampilan `pg_stat_statements` untuk mengidentifikasi akar penyebab, parameter dapat dinonaktifkan dengan menyetelnya ke. `pg_stat_statements.track` `none` Ini akan menonaktifkan pengumpulan statistik pernyataan.
### Meningkatkan parameter pg\$1stat\$1statements.max
Untuk mengurangi deallocation dan meminimalkan pengumpulan sampah `pgss_query_texts.stat` file pada disk, tingkatkan nilai `pg_stat_statements.max` parameter. Nilai default-nya adalah `5,000`.
**catatan**
`pg_stat_statements.max`Parameternya statis. Anda harus memulai ulang instans DB Anda untuk menerapkan perubahan apa pun pada parameter ini.
### Nonaktifkan parameter pg\$1stat\$1statements.track\$1utility
Anda dapat menganalisis tampilan pg\$1stat\$1statement untuk menentukan perintah utilitas mana yang paling banyak menggunakan sumber daya yang dilacak. `pg_stat_statements`
`pg_stat_statements.track_utility`Parameter mengontrol apakah modul melacak perintah utilitas, yang mencakup semua perintah kecuali SELECT, INSERT, UPDATE, DELETE, dan MERGE. Secara default, parameter ini diatur ke`on`.
Misalnya, ketika aplikasi Anda menggunakan banyak kueri savepoint, yang secara inheren unik, itu dapat meningkatkan deallocation pernyataan. Untuk mengatasinya, Anda dapat menonaktifkan `pg_stat_statements.track_utility` parameter untuk berhenti melacak `pg_stat_statements` kueri savepoint.
**catatan**
`pg_stat_statements.track_utility`Parameternya adalah parameter dinamis. Anda dapat mengubah nilainya tanpa memulai ulang instance database Anda.
**Example Contoh kueri titik simpan unik di pg\$1stat\$1statement**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 memperkenalkan beberapa penyempurnaan untuk pelacakan perintah utilitas:
+ Nama Savepoint sekarang ditampilkan sebagai konstanta.
+ Global Transaction IDs (GIDs) dari perintah komit dua fase sekarang ditampilkan sebagai konstanta.
+ Nama pernyataan DEALLOCATE ditampilkan sebagai konstanta.
+ Parameter CALL sekarang ditampilkan sebagai konstanta.
# Timeout:PgSleep
Peristiwa `Timeout:PgSleep` terjadi saat proses server telah memanggil fungsi `pg_sleep` dan menunggu batas waktu tidur berakhir.
**Topics**
+ [Versi mesin yang didukung](#apg-waits.timeoutpgsleep.context.supported)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-waits.timeoutpgsleep.causes)
+ [Tindakan](#apg-waits.timeoutpgsleep.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Peristiwa tunggu ini terjadi saat aplikasi, fungsi yang tersimpan, atau pengguna mengeluarkan pernyataan SQL yang memanggil salah satu fungsi berikut:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Fungsi sebelumnya menunda eksekusi hingga waktu yang ditentukan dalam detik telah berlalu. Misalnya, `SELECT pg_sleep(1)` dijeda selama 1 detik. Untuk informasi selengkapnya, lihat [Menunda Eksekusi](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) pada dokumentasi PostgreSQL.
## Tindakan
Identifikasi pernyataan yang menjalankan fungsi `pg_sleep`. Tentukan apakah penggunaan fungsi tersebut sesuai.