View a markdown version of this page

Pemecahan masalah awal untuk masalah kinerja PostgreSQL umum di RDS for PostgreSQL - 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.

Pemecahan masalah awal untuk masalah kinerja PostgreSQL umum di RDS for PostgreSQL

Panduan ini mencakup empat masalah kinerja paling umum yang mempengaruhi RDS untuk PostgreSQL database: kembung tabel dan indeks, kehabisan sumber daya kueri paralel, koneksi tinggi dan tekanan otentikasi, dan penyetelan autocacuum. Gunakan panduan ini sebagai daftar periksa diagnostik lolos pertama saat Anda mengalami penurunan kinerja, sebelum Anda memulai penyelidikan lebih dalam.

Setiap bagian menjelaskan gejala yang mungkin Anda amati, memberikan kueri diagnostik untuk mengkonfirmasi akar penyebab, dan merekomendasikan langkah-langkah remediasi tertentu.

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. Hal 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 perselisihan sumber daya:

  • Akumulasi kembung adalah perubahan beban kerja. Kontrol konkurensi multiversi (MVCC) PostgreSQL mempertahankan versi baris lama sampai autopacuum mengambilnya kembali. Ketika tupel mati menumpuk lebih cepat daripada autopacuum 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 bertambahnya 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 ketika 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 secara akurat mencerminkan distribusi untuk nilai-nilai tersebut. Ketika kembung juga hadir, dampaknya menjadi senyawa — rencana suboptimal sekarang memindai secara signifikan lebih banyak data mati.

  • Statistik bisa basi bahkan ketika autopacuum berjalan. Pemicu Autovacuum ANALYZE berdasarkan jumlah baris yang disisipkan atau diperbarui, bukan pada apakah distribusi data telah berubah secara berarti. Jika aplikasi Anda beralih ke menanyakan rentang nilai atau jendela waktu yang berbeda, perkiraan biaya perencana mungkin tidak akurat meskipun autopacuum 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 oleh kueri meningkat. Kueri yang berkinerja baik pada tabel yang lebih kecil dapat mengembangkan latensi seiring dengan bertambahnya ukuran tabel, bahkan ketika logika kueri dan indeks tetap tidak berubah. Memantau FreeStorageSpace untuk melacak tren pertumbuhan penyimpanan.

Saat Anda menyelidiki regresi kinerja di mana “tidak ada yang berubah,” perlakukan akumulasi kembung, rentang nilai parameter baru, pertumbuhan database 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-langkah triase berurutan berikut saat pertama kali menyelidiki masalah kinerja:

  1. Periksa pg_stat_activity. Lihatlah jumlah koneksi, sesi idle-in-transaksi, dan kueri yang berjalan lama. Untuk informasi lebih lanjut, lihat Konsep penting untuk RDS untuk penyetelan PostgreSQL.

  2. Periksa kembung. Cari tinggi n_dead_tup di pg_stat_user_tables dan pertimbangkan untuk menggunakan pgstattuple untuk pengukuran yang tepat. Untuk informasi lebih lanjut, lihat Menghapus kembung dari tabel dengan pg_repack.

  3. Periksa pg_stat_user_tables. Cari tinggi n_dead_tup nilai dan basi last_autovacuum stempel waktu. Untuk informasi lebih lanjut, lihat Bekerja dengan PostgreSQL autopacuum di Amazon RDS.

  4. Tinjauan EXPLAIN ANALYZE pada kueri lambat. Cari rencana paralel dan pemindaian berurutan pada tabel besar. Untuk informasi lebih lanjut, lihat Praktik terbaik untuk kueri paralel di RDS untuk PostgreSQL.

  5. Periksa CloudWatch dan metrik Wawasan Kinerja. Tinjau pemanfaatan CPU, jumlah koneksi, IOPS, dan memori yang dapat dibebaskan. Untuk informasi lebih lanjut, lihat Pemantauan Amazon RDS. Untuk peristiwa tunggu umum dan tindakan korektif, lihat RDS untuk acara tunggu PostgreSQL.

  6. Tinjau grup parameter DB Anda. Periksa max_parallel_workers_per_gather dan pengaturan autopacuum. Untuk informasi selengkapnya, lihat Bekerja dengan parameter pada instans DB RDS for PostgreSQL.

Tabel dan indeks kembung

Kembung tabel dan indeks terjadi ketika tupel mati menumpuk di tabel Anda lebih cepat daripada autopacuum dapat merebutnya kembali. Seiring waktu, hal ini menyebabkan penurunan kinerja kueri secara bertahap, peningkatan penggunaan penyimpanan, dan rencana kueri yang kurang optimal.

Gejala

  • Penurunan kinerja kueri bertahap selama berminggu-minggu atau bulan

  • Penggunaan penyimpanan tumbuh meskipun volume data stabil

  • Perencana kueri memilih pemindaian berurutan daripada pemindaian indeks karena statistik basi

  • Tinggi dead_tuple_count dalam tabel statistik

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 lebih lanjut, lihat Menghapus kembung dari tabel dengan pg_repack dan Hapus kembung dari Amazon Aurora dan RDS untuk PostgreSQL dengan pg_repack.

penting

Daripada mengandalkan perawatan manual, pastikan bahwa autopacuum 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 untuk pemindaian dan agregasi berurutan 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 menghabiskan 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 DatabaseConnections di CloudWatch tanpa perubahan aplikasi. Anda juga dapat mengamati peristiwa menunggu seperti IPC:BgWorkerStartup, IPC:ExecuteGather, dan IPC:ParallelFinish. Untuk informasi selengkapnya tentang acara tunggu ini, lihat IPC:parallel tunggu acara.

Untuk sebagian besar OLTP dan beban kerja produksi konkurensi tinggi, nonaktifkan paralelisme otomatis dengan menyetel max_parallel_workers_per_gather = 0 di grup parameter DB Anda. Anda kemudian dapat mengaktifkan paralelisme secara selektif untuk sesi analitik atau pelaporan tertentu dengan menyetel parameter per sesi atau per peran.

Untuk panduan terperinci tentang mendiagnosis dan mengendalikan perilaku kueri paralel, lihat Praktik terbaik untuk kueri paralel di RDS untuk PostgreSQL.

Koneksi tinggi dan tekanan otentikasi

Koneksi churn - sering membuka dan menutup koneksi database tanpa pengumpulan - menciptakan overhead otentikasi dan dapat menghabiskan slot koneksi yang tersedia. Koneksi idle yang tetap terbuka juga menghabiskan slot tanpa melakukan pekerjaan yang berguna.

Gejala

  • ditinggikan total_auth_attempts dalam pemantauan Wawasan Kinerja. Untuk informasi lebih lanjut, lihat Non-native penghitung untuk RDS untuk PostgreSQL.

  • Waktu pembentukan koneksi lambat

  • FATAL: too many connections for role atau remaining connection slots are reserved kesalahan

  • Lonjakan 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';

Sejumlah besar idle atau idle in transaction koneksi relatif terhadap max_connections menunjukkan bahwa koneksi tidak dilepaskan dengan benar. Idle-in-transaction koneksi sangat bermasalah karena mereka memegang kunci dan mencegah autocacuum merebut kembali tupel mati.

Remediasi

  • Terapkan pengumpulan koneksi. Gunakan PgBouncer atau Proksi Amazon RDS untuk mengurangi jumlah koneksi langsung ke database Anda. Pengumpulan koneksi menggunakan kembali koneksi yang ada daripada membuat yang baru untuk setiap permintaan.

  • Mengatur idle_in_transaction_session_timeout. Parameter ini secara otomatis mengakhiri sesi yang tetap tidak aktif dalam transaksi di luar durasi yang ditentukan. Ini mencegah transaksi idle yang berjalan lama dari menahan kunci dan memblokir autopacuum.

  • Tinjau penanganan koneksi aplikasi. Pastikan aplikasi Anda menutup koneksi dengan segera dan tidak menahan transaksi terbuka lebih lama dari yang diperlukan.

catatan

Pekerja kueri paralel mengkonsumsi CPU dan memori. Jika Anda mengamati kehabisan sumber daya di samping aktivitas kueri paralel, lihat Kelelahan sumber daya kueri paralel untuk panduan pengendalian penggunaan pekerja paralel.

Menggunakan Performance Insights menunggu peristiwa untuk pemecahan masalah

Performance Insights menangkap peristiwa tunggu yang menunjukkan di mana database Anda menghabiskan waktu. Saat Anda menyelidiki masalah kinerja, acara tunggu membantu Anda mengidentifikasi apakah hambatannya adalah CPU, I/O, penguncian, jaringan, 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 tunggu CPU tinggi sering berkorelasi dengan paralelisme yang berlebihan atau rencana kueri yang tidak efisien memindai tabel yang membengkak.

  • IPC (komunikasi antar-proses) — Tunggu acara seperti IPC:BgWorkerStartup, IPC:ExecuteGather, dan IPC:ParallelFinish menunjukkan overhead koordinasi kueri paralel.

  • IO — Tunggu acara seperti IO:DataFileRead menunjukkan bahwa kueri membaca data dari penyimpanan karena halaman yang diperlukan tidak dalam memori bersama. Hal ini biasa terjadi ketika tabel yang membengkak melebihi cache buffer.

  • Kunci — Tunggu acara seperti Lock:transactionid dan Lock:tuple menunjukkan perselisihan antar sesi. Idle-in-transaction koneksi dapat menahan kunci yang memblokir kueri lain dan autopacuum.

  • 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 peristiwa tunggu yang biasanya menunjukkan masalah kinerja dan tindakan korektif yang direkomendasikan, lihat RDS untuk acara tunggu PostgreSQL.

Penyetelan Autovacuum

Autovacuum adalah proses latar belakang yang mengklaim kembali tupel mati, mencegah kembung tabel dan indeks, memperbarui statistik perencana, dan melindungi dari pembungkus ID transaksi. Pengaturan auto acuum default konservatif dan dirancang untuk database kecil. High-write beban kerja produksi hampir selalu membutuhkan penyetelan.

Ketika autopacuum tidak dapat mengikuti beban kerja penulisan Anda, kembung menumpuk, statistik perencana menjadi basi, dan risiko pembungkus ID transaksi meningkat. Jika age(relfrozenxid) mendekati 2 miliar, database ditutup untuk mencegah korupsi data.

Untuk panduan terperinci tentang menyetel parameter autocacuum, memantau aktivitas vakum, dan mengonfigurasi penggantian per tabel, lihat Bekerja dengan PostgreSQL autopacuum di Amazon RDS.

Informasi Terkait