Preskoči na vsebino

Vzporedni delavci

Prikaži kot Markdown Uredi na GitHub Dokumentacija za d105217

Greph razporedi pregledovanje besedila in AST med skupino delavcev, ko je obseg dela dovolj velik, da upraviči režijske stroške. Skupina temelji na pcntl_fork() in preide na izvajanje znotraj procesa, kadar ext-pcntl ni na voljo (Windows, nekatera okolja PaaS in omejeno gostovanje).

Omogočanje vzporednega pregledovanja

Nastavite -j N v CLI ali jobs: N v ustreznem objektu z možnostmi:

Lupina
./vendor/bin/greph -F -j 8 "function" src
./vendor/bin/greph -p '$obj->$method($$$ARGS)' -j 4 src
./vendor/bin/rg --threads 8 -F "function" src
./vendor/bin/sg run --threads 8 --pattern '$obj->$method($$$ARGS)' src
PHP
use Greph\Greph;
use Greph\Text\TextSearchOptions;

Greph::searchText(
    'function',
    'src',
    new TextSearchOptions(fixedString: true, jobs: 8),
);

Kdaj se začne vzporedno izvajanje

Greph ne izvaja vzporedno v vseh primerih. Razvejitev v N procesov in izmenjava rezultatov prek cevi ustvarjata režijske stroške, ki pri majhnih seznamih datotek prevladajo nad samim iskanjem. Zato fasada izračuna prag glede na število opravil, način iskanja in obliko vzorca. V skupino delavcev se pošljejo samo seznami datotek, ki presegajo prag.

Trenutne hevristike (v Greph\Greph::shouldUseTextWorkers in sorodnih datotekah):

  • Zagoni z enim opravilom (-j 1) se vedno izvajajo znotraj procesa.
  • Pri običajnem pregledovanju besedila mora biti približno jobs * 2_000 datotek, da se vključi skupina.
  • Načini štetja, datotek z zadetki in datotek brez zadetkov znižajo prag na približno jobs * 750, ker je delo na posamezni datoteki cenejše.
  • Pri kratkih vzorcih fiksnih nizov, oblikovanih kot identifikatorji, se prag zviša na približno jobs * 4_000, ker je hitra pot za dobesedne nize že tako poceni, da se razvejanje redko izplača.
  • Iskanje in prepis AST uporabljata prag jobs * 750.

Te številke so hevristike, ne zagotovila. Prilagojene so korpusu primerjalnih preizkusov WordPress in se lahko spremenijo.

Kako deluje skupina

Greph\Parallel\WorkSplitter razdeli seznam datotek na N kosov. Greph\Parallel\WorkerPool razveji en delovni proces za vsak kos, vsak delavec zažene isto zaključeno funkcijo na svojem delu, Greph\Parallel\ResultCollector pa prebere serializirane rezultate prek para vtičnic Unix za vsakega delavca. Nadrejeni proces počaka na vse delavce, nato združi in znova razvrsti rezultate, da ostane vrstni red izhoda stabilen ne glede na razdelitev dela.

Za besedilni način skupina delavcev uporablja prilagojen kodek za prenos (Greph\Text\TextResultCodec), da ohrani serializirano vsebino kompaktno. Način AST uporablja standardni serialize(), ki ga ponuja PHP.

Ko pcntl ni na voljo

Če pcntl_fork ni mogoče klicati (Windows, utrjene gradnje PHP), skupina brez opozorila preide na izvajanje vseh kosov znotraj procesa. Rezultat je enak kot pri -j 1. Greph ne sproži napake; deluje le z eno nitjo.

To lahko med izvajanjem preverite z function_exists('pcntl_fork').

Nasveti za prilagajanje

  • Začnite tako, da nastavite -j na polovico števila fizičnih jeder, nato pa vrednost povečujte, dokler izboljšave ne prenehajo.
  • Pri iskanju samo dobesednih fiksnih nizov v majhnih repozitorijih je izvajanje v enem procesu običajno hitrejše od katere koli vzporedne konfiguracije.
  • Objavljeni primerjalni preizkusi ne merijo vzporednega iskanja ali prepisa AST. Preden določite število opravil, opravite meritve na svojem drevesu.
  • Vrstice README »Način pregledovanja: vzporedno besedilo« (1, 2 in 4 delavci na korpusu WordPress) ne merijo skupine: iščejo kratek dobesedni niz function, katerega prag jobs * 4_000 datotek presega velikost korpusa, zato se vse vrstice izvajajo znotraj enega procesa (#8).

Omejitve

  • Trenutna skupina ne podpira kraje opravil. Če je en kos veliko zahtevnejši od drugih, skupina čaka na najpočasnejšega delavca.
  • Rezultati delavcev se medpomnijo, dokler vsi ne končajo. Pretakanje izhoda dolgotrajnega pregledovanja (kot rg --json pretaka dogodke) v vzporednem načinu ni podprto.
  • Nadrejeni proces po združitvi znova razvrsti rezultate, zato skupina delavcev ne zmanjša največje porabe pomnilnika v primerjavi s pregledovanjem v enem procesu.

Te omejitve so sprejemljive za delovne obremenitve, na katere cilja Greph (interaktivno iskanje kode, zanke agentov, opravila CI nad posnetki). Ponovno jih bomo preučili, če profiliranje pokaže, da predstavljajo ozko grlo pri resničnih korpusih.