Prestasi PostgreSQL & Pengoptimuman Pertanyaan · Pelajaran

Mendiagnosis Sebab Keselarian Dilumpuhkan

Kenal pasti fungsi, kunci dan tetapan yang secara senyap memaksa pelaksanaan bersiri.

Pelajaran 4 daripada 413 langkah

Mendiagnosis Sebab Keselarian Dilumpuhkan ialah pelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan percuma di CoddyKit. Ini ialah pelajaran 4 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Prestasi PostgreSQL & Pengoptimuman Pertanyaan merangkumi sejumlah 4 pelajaran.

Apabila Pelan Berjalan Secara Bersiri

Anda menjangkakan imbasan berjujukan selari, tetapi EXPLAIN menunjukkan pelan bersiri biasa. Sebelum menyalahkan model kos perancang, fahami bahawa PostgreSQL mempunyai banyak gerbang mutlak yang boleh menolak keselarasan sepenuhnya tanpa memberikan petunjuk jelas.

Sesetengahnya ialah tetapan (bilangan pekerja ditetapkan kepada 0, parallel_setup_cost yang rendah masih terlalu tinggi).
Sesetengahnya ialah bentuk pertanyaan (fungsi yang tidak selamat untuk keselarasan, CTE penulisan).
Sesetengahnya berlaku semasa masa jalan (tiada slot pekerja yang kosong atau kunci sedang dipegang).

Tugas kita dalam pelajaran ini adalah mencari secara sistematik gerbang yang mana telah dicetuskan.

Pandangan Pertama: EXPLAIN ANALYZE

Mulakan dengan mengesahkan sama ada keselarasan muncul langsung. Pelan selari mengandungi nod Gather (atau Gather Merge) di atas imbasan sedar selari. Jika anda hanya melihat Seq Scan biasa, tiada pekerja yang dianggap sesuai.

Baris Workers Planned dan Workers Launched memberitahu sama ada perancang mahukan pekerja dan sama ada pekerja itu benar-benar diperoleh semasa masa jalan — dua kegagalan yang sangat berbeza.

EXPLAIN (ANALYZE, VERBOSE, BUFFERS)
SELECT count(*)
FROM orders
WHERE amount > 100;

-- Look for:
--   Gather  (cost=...)
--     Workers Planned: 2
--     Workers Launched: 2
--     ->  Parallel Seq Scan on orders

Dirancang berbanding Dilancarkan: Dua Mod Kegagalan

Bezakan kedua-dua gejala ini dengan tepat:

Workers Planned: 0 — perancang memutuskan bahawa keselarasan tidak dibenarkan atau tidak berbaloi. Ini ialah gerbang pada masa perancangan (tetapan, pertanyaan yang tidak selamat untuk keselarasan atau kos).
Workers Planned: 2, Workers Launched: 0 — pelan itu selari, tetapi tiada slot pekerja yang kosong semasa pelaksanaan. Ini ialah masalah kehabisan sumber pada masa jalan.

Mengelirukan kedua-duanya boleh membazirkan masa berjam-jam. Sentiasa baca kedua-dua baris sebelum membentuk hipotesis.

Gerbang 1: Tetapan Pekerja

Punca paling lazim bagi Workers Planned: 0 ialah konfigurasi. Semak tiga perkara ini dahulu:

max_parallel_workers_per_gather — jika 0, keselarasan dilumpuhkan secara global untuk pertanyaan. Inilah punca utama.
max_parallel_workers — saiz kumpulan; mesti > 0 dan ≤ max_worker_processes.
max_worker_processes — had mutlak untuk semua pekerja latar belakang.

Periksa semuanya sekali gus:

SELECT name, setting, source
FROM pg_settings
WHERE name IN (
  'max_parallel_workers_per_gather',
  'max_parallel_workers',
  'max_worker_processes',
  'max_parallel_maintenance_workers'
);

Gerbang 2: Saiz Jadual dan Ambang Kos

Walaupun pekerja diaktifkan, perancang menolak keselarasan apabila hubungan kelihatan terlalu kecil. Dua tetapan mengawal perkara ini:

min_parallel_table_scan_size (lalai 8MB) — timbunan yang lebih kecil daripada saiz ini tidak akan diimbas secara selari.
min_parallel_index_scan_size (lalai 512kB) — konsep yang sama untuk imbasan indeks.

Selain itu, parallel_setup_cost (lalai 1000) dan parallel_tuple_cost (lalai 0.1) mengenakan penalti pada pelan selari; untuk hasil yang kecil, pelan bersiri hanya menang dari segi kos. Semak saiz sebenar jadual:

SELECT pg_size_pretty(pg_relation_size('orders')) AS heap_size,
       (pg_relation_size('orders') / 1024.0 / 1024.0) AS heap_mb,
       current_setting('min_parallel_table_scan_size') AS min_scan;

Gerbang 3: Fungsi yang Tidak Selamat untuk Keselarasan

Satu fungsi PARALLEL UNSAFE sahaja di mana-mana dalam pertanyaan akan memaksa seluruh pelan berjalan secara bersiri — tiada Gather langsung. Setiap fungsi mempunyai label keselamatan selari:

SAFE — boleh berjalan dalam pekerja.
RESTRICTED — boleh muncul dalam pelan tetapi hanya pada peneraju, bukan di bawah Gather.
UNSAFE — melarang keselarasan untuk keseluruhan pernyataan.

Fungsi yang ditakrifkan pengguna secara lalai ialah UNSAFE melainkan anda menandakannya secara jelas. Apa-apa sahaja yang menulis, menggunakan jujukan atau menyentuh jadual sementara adalah tidak selamat.

SELECT p.proname,
       p.proparallel  -- 's'=safe, 'r'=restricted, 'u'=unsafe
FROM pg_proc p
WHERE p.proname IN ('normalize_email', 'nextval', 'random', 'now')
ORDER BY p.proname;

Mengaudit Fungsi Anda Sendiri

Untuk mencari UDF yang melumpuhkan keselarasan secara senyap, senaraikan setiap fungsi milik anda yang dilabelkan sebagai tidak selamat atau terhad. Fungsi yang secara logiknya tulen tetapi secara lalai berstatus UNSAFE ialah punca tersembunyi yang kerap berlaku.

Jika fungsi itu benar-benar hanya membaca dan bebas kesan sampingan, isytiharkan semula fungsi tersebut sebagai PARALLEL SAFE untuk membuka laluan kepada perancang.

SELECT n.nspname AS schema,
       p.proname AS function,
       CASE p.proparallel
         WHEN 's' THEN 'safe'
         WHEN 'r' THEN 'restricted'
         WHEN 'u' THEN 'unsafe'
       END AS parallel_safety
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname NOT IN ('pg_catalog', 'information_schema')
  AND p.proparallel <> 's'
ORDER BY 1, 2;

Membaiki Label UDF yang Tidak Selamat

Jika anda mengesahkan bahawa fungsi tidak mempunyai kesan sampingan dan tidak pernah menulis, tandainya sebagai selamat supaya fungsi itu boleh berjalan di bawah Gather. Bersikap jujur: apa-apa yang memanggil nextval(), mengubah jadual atau menggunakan keadaan sesi yang tidak boleh ubah mesti kekal terhad atau tidak selamat.

Menandai fungsi yang benar-benar tidak selamat sebagai selamat boleh menghasilkan keputusan yang salah atau menyebabkan pekerja ranap — label ini ialah suatu perjanjian, bukan sekadar petunjuk.

-- Only if the body is truly read-only and deterministic across workers:
ALTER FUNCTION normalize_email(text) PARALLEL SAFE;

-- Verify the new label:
SELECT proname, proparallel
FROM pg_proc
WHERE proname = 'normalize_email';

Gerbang 4: Bentuk Pertanyaan yang Menghalang Keselarasan

Sesetengah binaan sememangnya terhad kepada pelaksanaan selari tanpa mengira tetapan:

Pernyataan yang mengubah data — INSERT/UPDATE/DELETE (DML selari adalah terhad; penulisan selari biasanya tidak digunakan).
CTE yang boleh ditulis / mengubah data — CTE yang melakukan penulisan memaksa pelaksanaan bersiri.
SELECT ... FOR UPDATE / FOR SHARE — klausa penguncian adalah terhad kepada pelaksanaan selari.
Pertanyaan di dalam fungsi dengan PARALLEL UNSAFE, atau dipanggil apabila pernyataan luar sudah merupakan operasi penulisan.
FULL OUTER JOIN secara sejarahnya, serta subpertanyaan berkorelasi yang merujuk nod selari luar.

Jika pertanyaan anda mempunyai mana-mana perkara ini, tiada tetapan yang akan menghasilkan pelan selari.

-- This SELECT can be parallel:
EXPLAIN SELECT count(*) FROM orders WHERE amount > 100;

-- This one cannot — the locking clause is parallel-restricted:
EXPLAIN SELECT * FROM orders WHERE amount > 100 FOR UPDATE;

Pintu 5: Kehabisan Pekerja Semasa Jalan Masa

Apabila anda melihat Workers Planned: 4 tetapi Workers Launched: 1, perancang adalah betul tetapi kumpulan pekerja kosong. Kumpulan seluruh kluster dihadkan oleh max_parallel_workers, diperoleh daripada max_worker_processes, dan dikongsi dengan autovakum serta pertanyaan selari yang lain.

Semasa konkurensi, pertanyaan mengambil slot yang masih ada — kadangkala tiada satu pun. Pantau bahagian belakang yang aktif untuk mengesahkan persaingan:

SELECT pid, backend_type, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE backend_type = 'parallel worker'
   OR query ILIKE '%Gather%'
ORDER BY backend_type;

Pintu 6: Kunci dan force_parallel_mode

Dua pintu terakhir yang mudah terlepas pandang:

Kunci berat — jika bahagian belakang memegang atau menunggu kunci yang bercanggah, ia mungkin dilaksanakan secara bersiri; selain itu, hubungan yang berada di bawah kunci ACCESS EXCLUSIVE (DDL) tidak akan mendapat imbasan selari semasa disekat. Periksa pg_locks yang digabungkan dengan pg_stat_activity.
debug_parallel_query (dahulunya force_parallel_mode) — GUC untuk pengujian. Menetapkannya kepada on/regress memaksa Gather walaupun tindakan itu tidak munasabah, yang boleh menyembunyikan diagnosis sebenar. Pastikan ia off semasa penyiasatan biasa.

SELECT name, setting
FROM pg_settings
WHERE name IN ('debug_parallel_query', 'force_parallel_mode');

-- Who is blocking a parallel scan?
SELECT l.pid, l.mode, l.granted, a.query
FROM pg_locks l
JOIN pg_stat_activity a ON a.pid = l.pid
WHERE l.relation = 'orders'::regclass
ORDER BY l.granted;

Semakan Pantas: Mendiagnosis Gejala

Seorang penganalisis menjalankan EXPLAIN ANALYZE dan melihat Workers Planned: 4 tetapi Workers Launched: 0. Semua GUC pekerja bukan sifar dan jadual berukuran 2 GB. Apakah punca yang paling berkemungkinan?

Jawab dalam pelajaran interaktif

Ringkasan: Senarai Semak Diagnosis

Untuk mencari sebab pelaksanaan selari dilumpuhkan, lakukan pemeriksaan dari atas ke bawah:

Baca kedua-dua baris. Workers Planned: 0 = pintu perancangan; Planned>0, Launched<Planned = kehabisan sumber semasa jalan masa.
Tetapan: semak max_parallel_workers_per_gather (≠0), max_parallel_workers, max_worker_processes.
Saiz/kos: jadual melebihi min_parallel_table_scan_size; parallel_setup_cost tidak mendominasi hasil yang kecil.
Fungsi: cari proparallel <> 's' dalam pg_proc; betulkan UDF yang dilabel secara salah.
Bentuk pertanyaan: penulisan, CTE yang mengubah data, klausa penguncian FOR UPDATE.
Jalan masa: pg_stat_activity untuk slot yang kosong; pg_locks untuk penyekat; sahkan debug_parallel_query = off.

Padankan gejala dengan pintunya, dan pelan bersiri yang senyap tidak lagi menjadi misteri.

Percuma untuk bermula

Pelajari SQL dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus: 22
Pelajaran: 88

Mula belajar secara percuma Lihat kursus penuh

Soalan Lazim

Adakah pelajaran “Mendiagnosis Sebab Keselarian Dilumpuhkan” percuma?

Ya — sebanyak 3 pelajaran dalam laluan pembelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan, termasuk “Mendiagnosis Sebab Keselarian Dilumpuhkan”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus Prestasi PostgreSQL & Pengoptimuman Pertanyaan merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Mendiagnosis Sebab Keselarian Dilumpuhkan”?

Kenal pasti fungsi, kunci dan tetapan yang secara senyap memaksa pelaksanaan bersiri. Anda berlatih Prestasi PostgreSQL & Pengoptimuman Pertanyaan menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Prestasi PostgreSQL & Pengoptimuman Pertanyaan?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 4 daripada 4.

Berapa lamakah pelajaran “Mendiagnosis Sebab Keselarian Dilumpuhkan” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan ini?

Ya. Setiap pelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

Bila Perancang Memilih Pelan Selari
Menala Bilangan Pekerja dan Kos Pengumpulan
Pengagregatan Selari dan Gabungan Cincangan
Mendiagnosis Sebab Keselarian Dilumpuhkan

← Kembali ke Prestasi PostgreSQL & Pengoptimuman Pertanyaan