View a markdown version of this page

IPC:parallel tunggu acara - Amazon Relational Database Service
Versi mesin yang didukungKonteksKemungkinan penyebab peningkatan peristiwa tungguTindakan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

IPC:parallel tunggu acara

Berikut ini IPC:parallel wait events menunjukkan bahwa sesi sedang menunggu komunikasi antar proses terkait dengan operasi eksekusi kueri paralel.

  • IPC:BgWorkerStartup- Suatu proses sedang menunggu proses pekerja paralel untuk menyelesaikan urutan startup-nya. Ini terjadi saat menginisialisasi pekerja untuk eksekusi kueri paralel.

  • IPC:BgWorkerShutdown- Suatu proses sedang menunggu proses pekerja paralel untuk menyelesaikan urutan penutupannya. Ini terjadi selama fase pembersihan eksekusi kueri paralel.

  • IPC:ExecuteGather- Sebuah proses sedang menunggu untuk menerima data dari proses pekerja paralel selama eksekusi kueri. Ini terjadi ketika proses pemimpin perlu mengumpulkan hasil dari pekerjanya.

  • IPC:ParallelFinish- Suatu proses sedang menunggu pekerja paralel untuk menyelesaikan eksekusi mereka dan melaporkan hasil akhir mereka. Ini terjadi selama fase penyelesaian eksekusi kueri paralel.

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.

Konteks

Eksekusi kueri paralel di PostgreSQL melibatkan beberapa proses yang bekerja bersama untuk memproses satu kueri. Ketika kueri ditentukan cocok untuk paralelisasi, proses pemimpin berkoordinasi dengan satu atau lebih proses pekerja paralel berdasarkan pengaturan max_parallel_workers_per_gather parameter. Proses pemimpin membagi pekerjaan di antara pekerja, setiap pekerja memproses porsi datanya secara independen, dan hasilnya dikumpulkan kembali ke proses pemimpin.

catatan

Setiap pekerja paralel beroperasi sebagai proses terpisah dengan persyaratan sumber daya yang mirip dengan sesi pengguna penuh. Ini berarti kueri paralel dengan 4 pekerja dapat mengkonsumsi hingga 5 kali sumber daya (CPU, memori, I/O bandwidth) dibandingkan dengan kueri non-paralel, karena proses pemimpin dan setiap proses pekerja mempertahankan alokasi sumber daya mereka sendiri. Misalnya, pengaturan seperti diterapkan work_mem secara individual untuk setiap pekerja, berpotensi mengalikan total penggunaan memori di semua proses.

Arsitektur kueri paralel terdiri dari tiga komponen utama:

  • Proses pemimpin: Proses utama yang memulai operasi paralel, membagi beban kerja, dan berkoordinasi dengan proses pekerja.

  • Proses pekerja: Proses latar belakang yang mengeksekusi bagian kueri secara paralel.

  • Gather/Gather menggabungkan: Operasi yang menggabungkan hasil dari beberapa proses pekerja kembali ke pemimpin

Selama eksekusi paralel, proses perlu berkomunikasi satu sama lain melalui mekanisme Inter-Process Komunikasi (IPC). Peristiwa tunggu IPC ini terjadi selama fase yang berbeda:

  • Startup pekerja: Saat pekerja paralel sedang diinisialisasi

  • Pertukaran data: Ketika pekerja memproses data dan mengirim hasil ke pemimpin

  • Penutupan pekerja: Ketika eksekusi paralel selesai dan pekerja dihentikan

  • Titik sinkronisasi: Ketika proses perlu mengoordinasikan atau menunggu proses lain untuk menyelesaikan tugasnya

Memahami peristiwa tunggu ini sangat penting untuk mendiagnosis masalah kinerja yang terkait dengan eksekusi kueri paralel, terutama di lingkungan konkurensi tinggi di mana beberapa kueri paralel dapat dijalankan secara bersamaan.

Kemungkinan penyebab peningkatan peristiwa tunggu

Beberapa faktor dapat berkontribusi pada peningkatan peristiwa tunggu IPC terkait paralel:

Konkurensi tinggi dari kueri paralel

Ketika banyak kueri paralel berjalan secara bersamaan, hal itu dapat menyebabkan perselisihan sumber daya dan peningkatan waktu tunggu untuk operasi IPC. Hal ini sangat umum terjadi pada sistem dengan volume transaksi tinggi atau beban kerja analitis.

Rencana kueri paralel yang tidak optimal

Jika perencana kueri memilih rencana paralel yang tidak efisien, hal itu dapat mengakibatkan paralelisasi yang tidak perlu atau distribusi pekerjaan yang buruk di antara pekerja. Hal ini dapat menyebabkan peningkatan penantian IPC, terutama untuk IPC:ExecuteGather dan IPC:ParallelFinish acara. Masalah perencanaan ini sering berasal dari statistik yang ketinggalan zaman dan kem table/index bung.

Sering memulai dan mematikan pekerja paralel

Short-lived kueri yang sering memulai dan menghentikan pekerja paralel dapat menyebabkan peningkatan IPC:BgWorkerStartup dan IPC:BgWorkerShutdown peristiwa. Ini sering terlihat dalam beban kerja OLTP dengan banyak kueri kecil yang dapat disejajarkan.

Kendala sumber daya

CPU, memori, atau I/O kapasitas yang terbatas dapat menyebabkan hambatan dalam eksekusi paralel, yang menyebabkan peningkatan waktu tunggu di semua peristiwa IPC. Misalnya, jika CPU jenuh, proses pekerja mungkin membutuhkan waktu lebih lama untuk memulai atau memproses bagian pekerjaan mereka.

Struktur kueri yang kompleks

Kueri dengan beberapa tingkat paralelisme (misalnya, gabungan paralel diikuti oleh agregasi paralel) dapat menyebabkan pola IPC yang lebih kompleks dan berpotensi meningkatkan waktu tunggu, terutama untuk peristiwa. IPC:ExecuteGather

Set hasil besar

Kueri yang menghasilkan kumpulan hasil yang besar dapat menyebabkan peningkatan waktu IPC:ExecuteGather tunggu karena proses pemimpin menghabiskan lebih banyak waktu mengumpulkan dan memproses hasil dari proses pekerja.

Memahami faktor-faktor ini dapat membantu dalam mendiagnosis dan mengatasi masalah kinerja yang terkait dengan eksekusi kueri paralel di Aurora PostgreSQL.

Tindakan

Ketika Anda melihat penantian terkait dengan kueri paralel, biasanya berarti bahwa proses backend sedang mengoordinasikan atau menunggu proses pekerja paralel. Penantian ini biasa terjadi selama pelaksanaan rencana paralel. Anda dapat menyelidiki dan mengurangi dampak penantian ini dengan memantau penggunaan pekerja paralel, meninjau pengaturan parameter, dan menyetel eksekusi kueri dan alokasi sumber daya.

Analisis rencana kueri untuk paralelisme yang tidak efisien

Eksekusi kueri paralel sering dapat menyebabkan ketidakstabilan sistem, lonjakan CPU, dan varians kinerja kueri yang tidak dapat diprediksi. Sangat penting untuk menganalisis secara menyeluruh apakah paralelisme benar-benar meningkatkan beban kerja spesifik Anda. Gunakan EXPLAIN ANALYZE untuk meninjau rencana eksekusi kueri paralel.

Nonaktifkan sementara paralelisme di tingkat sesi untuk membandingkan efisiensi rencana:


SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;

Re-enable paralelisme dan perbandingan:


RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;

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 pada tingkat instance dengan menyesuaikan parameter yang relevan di grup parameter DB Anda. Untuk informasi selengkapnya, lihat Memodifikasi parameter dalam grup parameter DB di Amazon RDS.

Pantau penggunaan kueri paralel

Gunakan kueri berikut untuk mendapatkan visibilitas ke aktivitas kueri paralel dan kapasitas:

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_parallel_workers` 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 kueri paralel. Angka tinggi di sini menunjukkan bahwa beberapa sesi menjalankan kueri paralel secara bersamaan, yang dapat meningkatkan permintaan pada CPU dan memori.

Tinjau dan sesuaikan pengaturan kueri paralel

Tinjau parameter berikut untuk memastikan mereka selaras dengan beban kerja Anda:

  • max_parallel_workers: Jumlah total pekerja paralel di semua sesi.

  • max_parallel_workers_per_gather: Maks pekerja 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 vCPU jika secara konsisten tinggi dan jika aplikasi Anda mendapat manfaat dari kueri paralel. Pastikan memori yang memadai tersedia untuk operasi paralel.

  • Gunakan metrik penghitung per-kueri dan basis data terperinci untuk menentukan apakah sistemnya benar CPU-bound.

  • Setiap pekerja paralel menggunakan miliknya sendiriwork_mem. Pastikan total penggunaan memori berada dalam batas instance.

Kueri paralel dapat mengkonsumsi sumber daya yang jauh lebih banyak daripada kueri non-paralel, karena setiap proses pekerja adalah proses yang sepenuhnya 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, sepertiwork_mem. Untuk informasi selengkapnya, lihat Dokumentasi PostgreSQL. Batas sumber daya seperti diterapkan work_mem 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 vCPU atau menyetel parameter memori jika beban kerja Anda sangat paralel.

Selidiki manajemen koneksi

Jika mengalami kelelahan koneksi, tinjau strategi pengumpulan koneksi aplikasi. Pertimbangkan untuk menerapkan pengumpulan koneksi di tingkat aplikasi jika belum digunakan.

Meninjau dan mengoptimalkan operasi pemeliharaan

Mengkoordinasikan pembuatan indeks dan tugas pemeliharaan lainnya untuk mencegah perselisihan sumber daya. Pertimbangkan untuk menjadwalkan operasi ini selama jam di luar jam sibuk. Hindari penjadwalan pemeliharaan berat (misalnya, pembuatan indeks paralel) selama periode beban kueri pengguna yang tinggi. Operasi ini dapat mengkonsumsi pekerja paralel dan berdampak pada kinerja untuk kueri reguler.