IPC: Acara tunggu paralel - Amazon Aurora
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: Acara tunggu paralel

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

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

  • IPC:BgWorkerShutdown- Sebuah proses sedang menunggu proses parallel worker untuk menyelesaikan urutan shutdown-nya. Ini terjadi selama fase pembersihan eksekusi query paralel.

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

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

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.

Konteks

Eksekusi query paralel di PostgreSQL melibatkan beberapa proses yang bekerja sama untuk memproses satu query. Ketika kueri ditentukan cocok untuk paralelisasi, proses pemimpin berkoordinasi dengan satu atau lebih proses pekerja paralel berdasarkan pengaturan parameter. max_parallel_workers_per_gather 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 query 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 ke setiap pekerja, berpotensi mengalikan total penggunaan memori di semua proses.

Arsitektur query 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 dari kueri secara paralel.

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

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

  • Startup pekerja: Ketika pekerja paralel sedang diinisialisasi

  • Pertukaran data: Ketika pekerja memproses data dan mengirimkan hasil kepada pemimpin

  • Worker shutdown: 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 acara tunggu IPC terkait paralel:

Konkurensi tinggi dari query paralel

Ketika banyak query paralel berjalan secara bersamaan, hal itu dapat menyebabkan pertentangan sumber daya dan peningkatan waktu tunggu untuk operasi IPC. Ini sangat umum dalam sistem dengan volume transaksi tinggi atau beban kerja analitis.

Rencana kueri paralel suboptimal

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

Sering startup dan shutdown pekerja paralel

Pertanyaan berumur pendek yang sering memulai dan menghentikan pekerja paralel dapat menyebabkan peningkatan dan peristiwa. IPC:BgWorkerStartup IPC:BgWorkerShutdown Ini sering terlihat pada beban kerja OLTP dengan banyak kueri kecil yang dapat diparalelkan.

Kendala sumber daya

CPU, memori, atau I/O kapasitas yang terbatas dapat menyebabkan kemacetan 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 acara. 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 untuk 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 waits terkait dengan query paralel, biasanya berarti bahwa proses backend sedang mengkoordinasikan atau menunggu proses parallel worker. Penantian ini biasa terjadi selama pelaksanaan rencana paralel. Anda dapat menyelidiki dan mengurangi dampak menunggu ini dengan memantau penggunaan pekerja paralel, meninjau pengaturan parameter, dan menyetel eksekusi kueri dan alokasi sumber daya.

Menganalisis rencana kueri untuk paralelisme yang tidak efisien

Eksekusi kueri paralel seringkali 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 EXPLORE ANALYZE untuk meninjau rencana eksekusi query paralel.

Nonaktifkan paralelisme sementara di tingkat sesi untuk membandingkan efisiensi rencana:


SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;

Aktifkan kembali paralelisme dan bandingkan:


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 di tingkat instans dengan menyesuaikan parameter yang relevan di cluster atau grup parameter instance Anda. Untuk informasi selengkapnya, lihat Parameter Amazon Aurora PostgreSQL.

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_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 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 sendiriwork_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. 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

Mengkoordinasikan 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 .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_hint_plan. Untuk informasi selengkapnya, lihat Memperbaiki rencana menggunakan pg_hint_plan. Anda dapat menggunakan petunjuk bernama Parallel untuk menegakkan eksekusi paralel. Untuk informasi selengkapnya, lihat Petunjuk untuk rencana paralel.