View a markdown version of this page

- Amazon Relational Database Service
Daftar periksa diagnostik cepatTabel dan indeks kembungKelelahan sumber daya kueri paralelKoneksi tinggi dan tekanan otentikasiMenggunakan Performance Insights menunggu peristiwa untuk pemecahan masalahPenyetelan autovacuumInformasi Terkait

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:

Daftar periksa diagnostik cepat

Gunakan langkah triase berurutan berikut saat pertama kali menyelidiki masalah kinerja:

  1. Periksapg_stat_activity. Lihat jumlah koneksi, sesi idle-in-transaction, dan kueri yang sudah berjalan lama. Untuk informasi lebih lanjut, lihat .

  2. 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.

  3. Periksapg_stat_user_tables. Cari n_dead_tup nilai tinggi dan stempel waktu basilast_autovacuum. Untuk informasi lebih lanjut, lihat Bekerja dengan PostgreSQL autovacuum di Amazon dengan PostgreSQL autovacuum di Aurora PostgreSQL.

  4. 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.

  5. Metrik Cek CloudWatch dan Performance Insights. Tinjau pemanfaatan CPU, jumlah koneksi, IOPS, dan memori yang dapat dibebaskan. Untuk informasi selengkapnya, lihat Monitoring Amazon RDS. Untuk kejadian menunggu umum dan tindakan korektif, lihat .

  6. 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.

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 .

penting

Daripada mengandalkan pemeliharaan manual, pastikan autovacuum diaktifkan dan disetel dengan benar untuk beban kerja Anda. Lihat Penyetelan 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-batasmax_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 sepertiIPC:BgWorkerStartup,IPC:ExecuteGather, danIPC:ParallelFinish. Untuk informasi selengkapnya tentang acara tunggu ini, lihat acara menunggu.

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 .

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.

  • Waktu pembentukan koneksi lambat

  • FATAL: too many connections for roleatau 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.

  • Setidle_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 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 sepertiIPC: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 .

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