Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
#
Panduan ini mencakup empat masalah kinerja paling umum yang memengaruhi : bloat tabel dan indeks, kelelahan sumber daya query paralel, koneksi tinggi dan tekanan otentikasi, dan penyetelan autovacuum. Gunakan panduan ini sebagai daftar periksa diagnostik pertama saat Anda mengalami penurunan kinerja, sebelum Anda memulai penyelidikan lebih dalam.
Setiap bagian menjelaskan gejala yang mungkin Anda amati, memberikan pertanyaan diagnostik untuk mengkonfirmasi akar penyebabnya, dan merekomendasikan langkah-langkah perbaikan khusus.
**Memahami regresi kinerja “tidak ada yang berubah”**
Beban kerja PostgreSQL sering berjalan tanpa masalah selama berminggu-minggu atau berbulan-bulan, kemudian mengalami penurunan kinerja mendadak meskipun kode aplikasi dan pola kueri tampak tidak berubah. Ini terjadi karena lingkungan database tidak pernah benar-benar statis — beberapa faktor tak terlihat bergeser dari waktu ke waktu dan dapat memicu perubahan rencana atau pertentangan sumber daya:
**Akumulasi kembung adalah perubahan beban kerja.** Kontrol konkurensi multiversi PostgreSQL (MVCC) mempertahankan versi baris lama hingga autovacuum merebutnya kembali. Ketika tupel mati menumpuk lebih cepat daripada autovacuum dapat memprosesnya, tabel dan indeks tumbuh secara fisik lebih besar. Perencana kueri kemudian dapat beralih dari pemindaian indeks yang efisien ke pemindaian berurutan karena perkiraan biaya bergeser seiring dengan meningkatnya ukuran tabel. SQL Anda tidak berubah, tetapi data yang dilihat perencana memiliki.
**Nilai parameter baru adalah perubahan beban kerja.** Kueri berparameter yang berkinerja baik untuk satu rentang nilai dapat berkinerja buruk saat aplikasi mulai menggunakan rentang yang berbeda. PostgreSQL dapat menggunakan kembali rencana eksekusi generik yang tidak memperhitungkan kemiringan data dalam rentang baru, atau statistik perencana mungkin tidak mencerminkan distribusi nilai tersebut secara akurat. Ketika kembung juga hadir, senyawa dampak - rencana suboptimal sekarang memindai lebih banyak data mati secara signifikan.
**Statistik bisa basi bahkan ketika autovacuum berjalan.** Autovacuum memicu `ANALYZE` berdasarkan jumlah baris yang dimasukkan atau diperbarui, bukan pada apakah distribusi data telah berubah secara bermakna. Jika aplikasi Anda bergeser ke kueri rentang nilai atau jendela waktu yang berbeda, perkiraan biaya perencana mungkin tidak akurat meskipun autovacuum telah berjalan baru-baru ini.
**Pertumbuhan database secara keseluruhan adalah perubahan beban kerja.** Seiring bertambahnya tabel dari waktu ke waktu, volume halaman data yang harus dipindai kueri meningkat. Kueri yang berkinerja baik pada tabel yang lebih kecil dapat mengembangkan latensi seiring bertambahnya ukuran tabel, bahkan ketika logika kueri dan indeks tetap tidak berubah. Pantau untuk melacak tren pertumbuhan penyimpanan.
Saat Anda menyelidiki regresi kinerja di mana “tidak ada yang berubah,” perlakukan akumulasi kembung, rentang nilai parameter baru, pertumbuhan basis data secara keseluruhan, dan statistik basi sebagai akar penyebab yang paling mungkin. Gunakan langkah-langkah diagnostik dalam panduan ini untuk mengonfirmasi faktor mana yang berlaku.
Untuk informasi selengkapnya, lihat berikut ini:
[Aktivitas pemeliharaan untuk database PostgreSQL di Amazon RDS dan Amazon Aurora (Panduan Preskriptif](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/introduction.html))AWS
[Mengoptimalkan kinerja kueri PostgreSQL (Panduan Preskriptif](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-query-tuning/introduction.html))AWS
[Menyetel parameter PostgreSQL di Amazon RDS dan Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/introduction.html)
[Metrik tingkat instans Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html#rds-cw-metrics-instance) (memantau `FreeStorageSpace` tren pertumbuhan penyimpanan)
## Daftar periksa diagnostik cepat
Gunakan langkah triase berurutan berikut saat pertama kali menyelidiki masalah kinerja:
1. **Periksa`pg_stat_activity`.** Lihat jumlah koneksi, sesi idle-in-transaction, dan kueri yang sudah berjalan lama. [Untuk informasi lebih lanjut, lihat .](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.html)
1. **Periksa kembung.** Cari high `n_dead_tup` in `pg_stat_user_tables` dan pertimbangkan `pgstattuple` untuk menggunakan pengukuran yang tepat. Untuk informasi selengkapnya, lihat [dari tabel dengan pg\_repack](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pg_repack.html).
1. **Periksa`pg_stat_user_tables`.** Cari `n_dead_tup` nilai tinggi dan stempel waktu basi`last_autovacuum`. Untuk informasi lebih lanjut, lihat [Bekerja dengan PostgreSQL autovacuum di Amazon dengan PostgreSQL autovacuum di](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) Aurora PostgreSQL.
1. **Tinjau `EXPLAIN ANALYZE` kueri lambat.** Cari rencana paralel dan pemindaian sekuensial pada tabel besar. Untuk informasi selengkapnya, lihat [PostgreSQL Praktik terbaik untuk kueri paralel di RDS untuk PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html).
1. **Metrik Cek CloudWatch dan Performance Insights.** Tinjau pemanfaatan CPU, jumlah koneksi, IOPS, dan memori yang dapat dibebaskan. Untuk informasi selengkapnya, lihat Monitoring [Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MonitoringOverview.html) RDS. [Untuk kejadian menunggu umum dan tindakan korektif, lihat .](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.summary.html)
1. **Tinjau grup parameter DB Anda.** Periksa `max_parallel_workers_per_gather` dan pengaturan autovacuum. Untuk informasi selengkapnya, lihat [Menyetel parameter PostgreSQL di Amazon RDS dan Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/introduction.html).
## Tabel dan indeks kembung
Tabel dan indeks kembung terjadi ketika tupel mati menumpuk di tabel Anda lebih cepat daripada autovacuum dapat merebutnya kembali. Seiring waktu, ini menyebabkan penurunan kinerja kueri secara bertahap, peningkatan penggunaan penyimpanan, dan rencana kueri suboptimal.
### Gejala
+ Degradasi kinerja kueri bertahap selama berminggu-minggu atau berbulan-bulan
+ Penggunaan penyimpanan tumbuh meskipun volume data stabil
+ Perencana kueri memilih pemindaian berurutan daripada pemindaian indeks karena statistik basi
+ Statistik `dead_tuple_count` tabel tinggi
### Diagnosis
Anda dapat memperkirakan kembung di semua tabel dengan menanyakan katalog sistem. Pendekatan ini tidak memerlukan ekstensi apa pun:
```
SELECT schemaname, relname,
n_dead_tup,
n_live_tup,
ROUND(n_dead_tup::numeric / GREATEST(n_live_tup, 1) * 100, 2) AS dead_pct,
last_autovacuum,
last_autoanalyze
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC
LIMIT 20;
```
Untuk mengatasi kembung, Anda dapat menggunakan `pg_repack` ekstensi untuk mengatur ulang tabel dan indeks dengan penguncian minimal. Untuk informasi selengkapnya, lihat [Menghapus bloat dari tabel dengan pg\_repack Menghapus bloat dari tabel dengan pg\_repack](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pg_repack.html) .
**penting**
Daripada mengandalkan pemeliharaan manual, pastikan autovacuum diaktifkan dan disetel dengan benar untuk beban kerja Anda. Lihat [Penyetelan autovacuum](#PostgreSQL.InitialTroubleshooting.Autovacuum) untuk rekomendasi penyetelan.
## Kelelahan sumber daya kueri paralel
PostgreSQL dapat mengeksekusi kueri secara paralel untuk meningkatkan kinerja pemindaian dan agregasi sekuensial besar. Namun, setiap pekerja paralel adalah proses backend penuh yang diperhitungkan `max_worker_processes` (dan sub-batas`max_parallel_workers`) dan mengalokasikan sendiri. `work_mem` Satu kueri dengan 4 pekerja paralel dapat mengkonsumsi ratusan megabyte memori dan CPU yang signifikan. Di bawah konkurensi tinggi, paralelisme yang berlebihan dapat menghabiskan CPU dan memori dengan cepat.
Gejala umum termasuk lonjakan CPU mendadak, penggunaan memori tinggi per kueri, dan peningkatan CloudWatch tanpa `DatabaseConnections` perubahan aplikasi. Anda juga dapat mengamati acara menunggu seperti`IPC:BgWorkerStartup`,`IPC:ExecuteGather`, dan`IPC:ParallelFinish`. Untuk informasi selengkapnya tentang acara tunggu ini, lihat [acara menunggu](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rpg-ipc-parallel.html).
Untuk sebagian besar beban kerja produksi OLTP dan konkurensi tinggi, nonaktifkan paralelisme otomatis dengan menyetel di grup parameter DB Anda. `max_parallel_workers_per_gather = 0` Anda kemudian dapat mengaktifkan paralelisme secara selektif untuk analisis atau sesi pelaporan tertentu dengan menetapkan parameter per sesi atau per peran.
[Untuk panduan terperinci tentang mendiagnosis dan mengendalikan perilaku kueri paralel, lihat .](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html)
## Koneksi tinggi dan tekanan otentikasi
Koneksi churn — sering membuka dan menutup koneksi database tanpa penyatuan — menciptakan overhead otentikasi dan dapat menghabiskan slot koneksi yang tersedia. Koneksi idle yang tetap terbuka juga mengkonsumsi slot tanpa melakukan pekerjaan yang bermanfaat.
### Gejala
+ Peningkatan `total_auth_attempts` dalam pemantauan Performance Insights. Untuk informasi lebih lanjut, lihat penghitung RDS untuk [Non-native PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html#USER_PerfInsights_Counters.PostgreSQL.NonNative).
+ Waktu pembentukan koneksi lambat
+ `FATAL: too many connections for role`atau `remaining connection slots are reserved` kesalahan
+ Paku CPU berkorelasi dengan churn koneksi
### Diagnosis
Jalankan kueri berikut untuk memeriksa status koneksi Anda saat ini:
```
SELECT
setting::int AS max_connections,
(SELECT count(*) FROM pg_stat_activity) AS current_connections,
(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle') AS idle_connections,
(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle in transaction') AS idle_in_txn
FROM pg_settings
WHERE name = 'max_connections';
```
Jumlah `idle` atau `idle in transaction` koneksi yang tinggi relatif terhadap `max_connections` menunjukkan bahwa koneksi tidak dilepaskan dengan benar. Idle-in-transaction koneksi sangat bermasalah karena menahan kunci dan mencegah autovacuum merebut kembali tupel mati.
### Remediasi
+ **Menyebarkan penyatuan koneksi.** Gunakan PgBouncer atau Amazon RDS Proxy untuk mengurangi jumlah koneksi langsung ke database Anda. Penggabungan koneksi menggunakan kembali koneksi yang ada daripada membuat yang baru untuk setiap permintaan.
+ **Set`idle_in_transaction_session_timeout`.** Parameter ini secara otomatis mengakhiri sesi yang tetap menganggur dalam transaksi di luar durasi yang ditentukan. Ini mencegah transaksi idle yang berjalan lama dari menahan kunci dan memblokir autovacuum.
+ **Tinjau penanganan koneksi aplikasi.** Pastikan aplikasi Anda menutup koneksi dengan segera dan tidak menahan transaksi terbuka lebih lama dari yang diperlukan.
**catatan**
Pekerja query paralel mengkonsumsi CPU dan memori. Jika Anda mengamati kehabisan sumber daya di samping aktivitas kueri paralel, lihat [Kelelahan sumber daya kueri paralel](#PostgreSQL.InitialTroubleshooting.ParallelQuery) panduan tentang cara mengontrol penggunaan pekerja paralel.
## Menggunakan Performance Insights menunggu peristiwa untuk pemecahan masalah
Performance Insights menangkap peristiwa tunggu yang menunjukkan tempat database Anda menghabiskan waktu. Saat Anda menyelidiki masalah kinerja, acara tunggu membantu Anda mengidentifikasi apakah kemacetannya adalah CPU, penguncian, jaringan I/O, atau komunikasi antar-proses. Kategori acara tunggu umum yang muncul selama masalah yang dijelaskan dalam panduan ini meliputi:
+ **CPU** — Sesi aktif pada CPU atau menunggu CPU. Peristiwa menunggu CPU yang tinggi sering berkorelasi dengan paralelisme yang berlebihan atau rencana kueri yang tidak efisien yang memindai tabel yang membengkak.
+ **IPC (inter-process communication)** — Tunggu peristiwa seperti`IPC:BgWorkerStartup`,`IPC:ExecuteGather`, dan tunjukkan overhead koordinasi query `IPC:ParallelFinish` paralel.
+ **IO** — Peristiwa tunggu seperti `IO:DataFileRead` menunjukkan bahwa kueri membaca data dari penyimpanan karena halaman yang diperlukan tidak berada dalam memori bersama. Ini biasa terjadi ketika tabel yang membengkak melebihi cache buffer.
+ **Kunci** — Tunggu acara seperti `Lock:transactionid` dan `Lock:tuple` tunjukkan perselisihan antar sesi. Idle-in-transaction koneksi dapat menahan kunci yang memblokir kueri dan autovacuum lainnya.
+ **Klien** — Tunggu acara seperti `Client:ClientRead` menunjukkan database sedang menunggu aplikasi untuk mengirim data. Peristiwa tunggu klien yang tinggi dapat menunjukkan churn koneksi atau latensi jaringan.
[Untuk referensi lengkap tentang peristiwa tunggu yang biasanya menunjukkan masalah kinerja dan tindakan korektif yang direkomendasikan, lihat .](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.summary.html)
## Penyetelan autovacuum
Autovacuum adalah proses latar belakang yang merebut kembali tupel mati, mencegah kembung tabel dan indeks, memperbarui statistik perencana, dan melindungi terhadap sampul ID transaksi. Pengaturan autovacuum default bersifat konservatif dan dirancang untuk database kecil. High-write beban kerja produksi hampir selalu membutuhkan penyetelan.
Ketika autovacuum tidak dapat mengikuti beban kerja tulis Anda, kembung menumpuk, statistik perencana menjadi basi, dan risiko sampul ID transaksi meningkat. Jika `age(relfrozenxid)` mendekati 2 miliar, database dimatikan untuk mencegah korupsi data.
## Informasi Terkait
+ [Praktik terbaik untuk query paralel di RDS untuk PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html)
+ [Penanganan koneksi mati di PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.html)
+ [Bekerja dengan PostgreSQL autovacuum di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
+ [Tugas DBA umum untuk RDS untuk PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html)
+ [Bekerja dengan PostgreSQL autovacuum di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
+ [Memahami autovacuum di lingkungan Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)