Työntekijämäärien ja Gather-kustannusten säätäminen
Säätäkää rinnakkaisten työntekijöiden asetuksia ja tuplekohtaisia kustannuksia nopeutuksen ja yleiskustannusten tasapainottamiseksi.
Työntekijämäärien ja Gather-kustannusten säätäminen on ilmainen PostgreSQL:n suorituskyky ja kyselyjen optimointi-oppitunti CoddyKitissä. Tämä on oppitunti 2/4. Voit lukea tästä oppimispolusta kokonaan mitkä tahansa 3 oppituntia ilmaiseksi — sen jälkeen CoddyKit PRO avaa kaikki oppitunnit sekä käytännön harjoittelun sisäänrakennetulla koodieditorilla ja ympäri vuorokauden toimivalla tekoälytuutorilla. Oppitunti kuuluu PostgreSQL:n suorituskyky ja kyselyjen optimointi-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. PostgreSQL:n suorituskyky ja kyselyjen optimointi-kurssilla on yhteensä 4 oppituntia.
Miksi rinnakkaiset kyselyt vaativat säätämistä
PostgreSQL voi jakaa yhden kyselyn useille suorittimen ytimille rinnakkaisten työntekijäprosessien avulla. Johtajaprosessi käynnistää apuprosessit, joista kukin skannaa oman osuutensa datasta, ja tulokset yhdistetään jälleen Gather-solmussa.
Rinnakkaisuus ei ole ilmaista. Työntekijäprosessien käynnistäminen, tuplejen kopioiminen jaetun muistin kautta ja synkronointi gather-kohdassa vievät kaikki aikaa. Pienillä tulosjoukoilla yleiskustannus voi ylittää nopeutuksesta saatavan hyödyn.
- Suoritinrajoitteiset työkuormat (suuret peräkkäiset skannaukset, aggregoinnit ja hash-liitokset) hyötyvät eniten.
- Viiveherkät lyhyet kyselyt eivät yleensä hyödy.
Tässä oppitunnissa käsitellään asetuksia, jotka määrittävät, kuinka monta työntekijäprosessia suoritetaan ja milloin suunnittelija pitää rinnakkaisuutta kannattavana.
Suunnitelman rakenne: Gather- ja Partial-solmut
Rinnakkaisella suunnitelmalla on tunnusomainen rakenne. Gather- (tai Gather Merge-)solmun alapuolella ovat partial-operaatiot, jotka työntekijäprosessit suorittavat rinnakkain; sen yläpuolella kaikki suoritetaan johtajaprosessissa peräkkäin.
Lue suunnitelma komennolla EXPLAIN (ANALYZE, VERBOSE) ja etsi kohtia Workers Planned ja Workers Launched. Niiden välinen ero tarkoittaa, että järjestelmän käytettävissä olevat työntekijäpaikat loppuivat suorituksen aikana.
EXPLAIN (ANALYZE, VERBOSE, BUFFERS)
SELECT count(*)
FROM orders
WHERE order_total > 100;
-- Look for:
-- Gather (cost=... rows=...)
-- Workers Planned: 2
-- Workers Launched: 2
-- -> Partial Aggregate
-- -> Parallel Seq Scan on ordersmax_parallel_workers_per_gather
Tärkein yksittäisen kyselyn asetus on max_parallel_workers_per_gather. Se rajoittaa, kuinka monta työntekijäprosessia yksi Gather-solmu voi pyytää. Oletusarvo on 2.
Arvon asettaminen arvoon 0 poistaa rinnakkaisuuden kokonaan käytöstä kyseisessä istunnossa. Arvon suurentaminen antaa suurille skannauksille mahdollisuuden käyttää useampia ytimiä, mutta vain taulun koon ja muiden rajoitusten sallimaan määrään asti.
- Tämä on Gather-kohtainen rajoitus, ei kyselykohtainen rajoitus. Kysely, jossa on kaksi Gather-solmua, voi käyttää enintään kaksi kertaa tämän määrän työntekijäprosesseja.
- Arvoa voi muuttaa istuntokohtaisesti komennolla
SET, joten yhtä raskasta raporttia voi säätää koskematta yleisiin asetuksiin.
-- Inspect current value
SHOW max_parallel_workers_per_gather;
-- Allow up to 4 workers per gather for this session
SET max_parallel_workers_per_gather = 4;
-- Disable parallelism for a latency-critical query
SET max_parallel_workers_per_gather = 0;Työntekijäbudjetin kolme tasoa
Työntekijäprosessien määrää rajoittavat kolme sisäkkäistä asetusta. Todellinen työntekijöiden määrä on kaikkien kolmen rajoituksen sekä suunnittelijan oman kokoon perustuvan arvion pienin.
max_parallel_workers_per_gather— Gather-solmukohtainen rajoitus (oletusarvo 2).max_parallel_workers— koko klusterin rinnakkaisille kyselyille varattu pooli (oletusarvo 8).max_worker_processes— koko palvelimen taustatyöntekijöiden kokonaismäärä, joka jaetaan laajennusten ja replikoinnin kanssa (oletusarvo 8).
Jos suurennat Gather-kohtaista rajoitusta mutta pidät arvon max_parallel_workers pienenä, samanaikaiset kyselyt kilpailevat resursseista ja monet suoritetaan suunniteltua pienemmällä työntekijämäärällä.
SHOW max_worker_processes; -- server-wide ceiling
SHOW max_parallel_workers; -- pool for parallel query
SHOW max_parallel_workers_per_gather; -- per-gather cap
-- A sane production starting point on an 8-core box:
-- max_worker_processes = 16
-- max_parallel_workers = 8
-- max_parallel_workers_per_gather = 4Miten suunnittelija valitsee oletusarvoisen työntekijämäärän
Suunnittelija skaalaa työntekijöiden määrää relaation koon perusteella logaritmisen säännön avulla, vaikka rajoitukset olisivat suuret. Taulun on oltava vähintään min_parallel_table_scan_size (oletusarvo 8 Mt), ennen kuin yhtäkään rinnakkaista työntekijäprosessia harkitaan. Karkeasti ottaen jokainen kolminkertainen koon kasvu lisää yhden työntekijän.
- 8 Mt → 24 Mt → 72 Mt → 216 Mt... → 1, 2, 3... työntekijäprosessia.
- Tämän jälkeen määrää rajoittaa
max_parallel_workers_per_gather.
Siksi pieni taulu ei koskaan muutu rinnakkaiseksi, vaikka rajoitukset asetettaisiin kuinka suuriksi — ja siksi min_parallel_table_scan_size -arvoa on joskus pienennettävä, jotta rinnakkaisia suunnitelmia voi testata pienellä datamäärällä.
SHOW min_parallel_table_scan_size; -- default 8MB
SHOW min_parallel_index_scan_size; -- default 512kB
-- Force consideration of parallelism on smaller tables (testing)
SET min_parallel_table_scan_size = '0';parallel_setup_cost: kiinteä yleiskustannus
parallel_setup_cost mallintaa työntekijäprosessien käynnistämisen ja jaetun muistin alustamisen kertaluonteisen hinnan. Oletusarvo on 1000 — suuri luku suunnittelijan kustannusyksiköissä, jotta optimoija välttäisi rinnakkaisuutta halvoissa kyselyissä.
Jos laitteistosi käynnistää työntekijäprosessit nopeasti ja hyvät rinnakkaiset suunnitelmat hylätään, tämän arvon pienentäminen saa suunnittelijan käyttämään rinnakkaisuutta herkemmin. Suurenna arvoa, jos haluat vähentää rinnakkaisuutta kuormitetussa OLTP-palvelimessa.
SHOW parallel_setup_cost; -- default 1000
-- Make the planner more eager to go parallel
SET parallel_setup_cost = 200;
-- Then compare plans
EXPLAIN SELECT count(*) FROM orders WHERE shipped_at IS NULL;parallel_tuple_cost: Gatherin tuplekohtainen hinta
parallel_tuple_cost mallintaa jokaisen tuplen siirtokustannuksen työntekijäprosessilta johtajaprosessille Gather-jonon kautta. Oletusarvo on 0.1 tuplea kohden.
Tämä on keskeinen syy siihen, miksi rinnakkaisuus häviää paljon rivejä palauttavissa kyselyissä: jokaisesta palautetusta tuplesta maksetaan kustannus. Rinnakkaiset suunnitelmat voittavat, kun työntekijäprosessit vähentävät datan määrää — suodattavat tehokkaasti tai aggregoivat — jolloin vain vähän tupleja kulkee Gather-solmun läpi.
- Gather-solmusta tuleva suuri rivimäärä + suuri
parallel_tuple_cost→ suunnittelija suosii peräkkäistä suoritusta. - Pienennä arvoa varovasti, jos tuplejen siirtäminen jaetussa muistissa on aidosti edullista.
SHOW parallel_tuple_cost; -- default 0.1
-- A query that aggregates (few tuples cross Gather) loves parallelism;
-- a query that returns millions of raw rows pays parallel_tuple_cost on each.
EXPLAIN
SELECT customer_id, count(*)
FROM orders
GROUP BY customer_id; -- partial aggregate shrinks data before GatherTaulukohtainen ohitus: parallel_workers-tallennusparametri
Voit määrittää tietylle taululle kiinteän työntekijämäärän parallel_workers-tallennusparametrilla. Tämä ohittaa suunnittelijan taulun kokoon perustuvan kaavan kyseisen taulun skannauksissa, mutta yleiset rajoitukset rajoittavat määrää edelleen.
Tämä on hyödyllistä paljon käytettävälle faktataululle, josta tehdään raskaita aggregointeja ja jossa haluat aina esimerkiksi 6 työntekijäprosessia logaritmisesti määräytyvän oletusarvon sijaan.
-- Pin parallel scans of this table to 6 workers
ALTER TABLE orders SET (parallel_workers = 6);
-- Remove the override, return to size-based defaults
ALTER TABLE orders RESET (parallel_workers);
-- Verify the setting
SELECT reloptions FROM pg_class WHERE relname = 'orders';Optimaalisen kohdan mittaaminen
Säätäminen perustuu kokeiluihin. Suorita sama kysely eri työntekijämäärillä ja vertaa todellista suoritusaikaa, älä pelkästään suunnittelijan kustannusta. Nopeutus on epälineaarista ja tasaantuu tai kääntyy lopulta heikkenemiseksi koordinoinnin yleiskustannusten kasvaessa.
- Seuraa kohtaa
Workers Launched— jos sen arvo on pienempi kuinWorkers Planned, poolisi on täynnä eikä Gather-kohtaisen rajoituksen suurentaminen auta. - Hyöty pienenee: siirtyminen 4 työntekijästä 8:aan tuottaa usein paljon pienemmän hyödyn kuin siirtyminen 1:stä 2:een.
SET max_parallel_workers_per_gather = 2;
EXPLAIN (ANALYZE, TIMING OFF) SELECT count(*) FROM orders WHERE order_total > 100;
SET max_parallel_workers_per_gather = 4;
EXPLAIN (ANALYZE, TIMING OFF) SELECT count(*) FROM orders WHERE order_total > 100;
SET max_parallel_workers_per_gather = 8;
EXPLAIN (ANALYZE, TIMING OFF) SELECT count(*) FROM orders WHERE order_total > 100;Samanaikaisuus: milloin työntekijäprosessit loppuvat
Rinnakkaisten työntekijäprosessien pooli jaetaan koko klusterin kesken. Samanaikaisessa kuormituksessa monet neljälle työntekijälle suunnitellut kyselyt voivat yhdessä vaatia enemmän kuin max_parallel_workers sallii, joten osa kyselyistä suoritetaan pienemmällä työntekijämäärällä tai ilman työntekijäprosesseja.
OLTP-painotteisissa järjestelmissä tämä on hyödyllistä: lyhyiden tapahtumien halutaan saavan suorittimen käyttöönsä, ei menettävän sitä raportointikyselylle, joka varasi 8 työntekijäprosessia. Toimintatapoja:
- Pidä
max_parallel_workers_per_gatheryleisesti kohtuullisena (2–4). - Suurenna arvoa istuntokohtaisesti vain tunnetuille eräajoille ja raportointitöille.
- Varmista, että
max_worker_processeson riittävän suuri, jotta laajennuksille ja replikoinnille jää myös tilaa.
Käytännön säätöohje
Yhdistetään nämä CPU-rajoitteisen analytiikkatyökuorman tapauksessa 8-ytimisellä palvelimella:
- Aseta
max_worker_processes = 16(tilaa laajennuksille). - Aseta
max_parallel_workers = 8(yksi ydintä kohden). - Pidä yleinen
max_parallel_workers_per_gather = 2OLTP-viiveen suojaamiseksi. - Aseta yöaikaisissa raportointi-istunnoissa
SET max_parallel_workers_per_gather = 6. - Pienennä arvoja
parallel_setup_cost/parallel_tuple_costvasta, kun EXPLAIN ANALYZE osoittaa, että hyviä suunnitelmia hylätään.
Varmista aina tulos todellisilla ajoilla ja määritä taulukohtaisia työntekijämääriä vain vakaille, hyvin tunnetuille paljon käytetyille tauluille.
-- Per-session profile for a heavy nightly aggregation job
SET max_parallel_workers_per_gather = 6;
SET parallel_setup_cost = 200;
SET min_parallel_table_scan_size = '4MB';
EXPLAIN (ANALYZE, BUFFERS)
SELECT region, date_trunc('day', created_at) AS d, sum(amount)
FROM sales
GROUP BY region, d;Pikatarkistus: työntekijävajeen selvittäminen
Suoritat raskaan aggregointikyselyn. EXPLAIN ANALYZE näyttää Workers Planned: 4, mutta Workers Launched: 1, ja suoritus on vain hieman nopeampi kuin peräkkäinen suoritus. Mikä yksittäinen muutos todennäköisimmin korjaa vajeen?
Kertaus: nopeutuksen ja yleiskustannusten tasapaino
Sinulla on nyt mielikuva rinnakkaisten kyselyiden säätämisestä:
- Työntekijäbudjetti on kerroksittainen: max_parallel_workers_per_gather ≤ max_parallel_workers ≤ max_worker_processes, ja taulun koko skaalaa määrää edelleen.
- Kustannukset ratkaisevat: parallel_setup_cost on käynnistämisestä perittävä kiinteä kustannus; parallel_tuple_cost veloitetaan jokaisesta Gather-solmun läpi kulkevasta tuplesta — joten rinnakkaisuus voittaa, kun työntekijäprosessit pienentävät datan määrää.
- Suunnitelman lukeminen on välttämätöntä: vertaamalla arvoja Workers Planned ja Workers Launched voit erottaa suunnitteluongelman suorituksen aikaisesta pooliongelmasta.
- Säädä istuntokohtaisesti, älä yleisesti, jotta OLTP-viive säilyy pienenä ja eräajot voivat silti käyttää suorittimen ytimiä.
Mittaa EXPLAIN ANALYZE -tulosteella ja todellisilla ajoilla; älä koskaan luota pelkästään suunnittelijan kustannukseen.
Opi SQL tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 22
- Oppitunnit
- 88
Usein kysytyt kysymykset
Onko oppitunti ”Työntekijämäärien ja Gather-kustannusten säätäminen” ilmainen?
Kyllä — voit lukea täällä verkossa kokonaan ilmaiseksi mitkä tahansa PostgreSQL:n suorituskyky ja kyselyjen optimointi-oppimispolun 3 oppituntia, myös oppitunnin “Työntekijämäärien ja Gather-kustannusten säätäminen”. Sen jälkeen CoddyKit PRO avaa kaikki oppitunnit sekä interaktiiviset harjoitukset sisäänrakennetulla koodieditorilla ja ympäri vuorokauden toimivalla tekoälytuutorilla. PostgreSQL:n suorituskyky ja kyselyjen optimointi-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Työntekijämäärien ja Gather-kustannusten säätäminen”?
Säätäkää rinnakkaisten työntekijöiden asetuksia ja tuplekohtaisia kustannuksia nopeutuksen ja yleiskustannusten tasapainottamiseksi. Harjoittelet PostgreSQL:n suorituskyky ja kyselyjen optimointi-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni PostgreSQL:n suorituskyky ja kyselyjen optimointi-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin PostgreSQL:n suorituskyky ja kyselyjen optimointi-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 2/4.
Kuinka kauan ”Työntekijämäärien ja Gather-kustannusten säätäminen”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä PostgreSQL:n suorituskyky ja kyselyjen optimointi-oppitunnilla?
Kyllä. Jokainen PostgreSQL:n suorituskyky ja kyselyjen optimointi-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Milloin suunnittelija valitsee rinnakkaiset suunnitelmat
- Työntekijämäärien ja Gather-kustannusten säätäminen
- Rinnakkainen aggregointi ja hash-liitokset
- Rinnakkaisuuden käytöstä poistamisen diagnosointi