Pereiti prie turinio

Išteklių valdymas

Peržiūrėti kaip Markdown Redaguoti per GitHub Dokumentacija: 2cc7b2b

Queuety išteklių valdymą skirsto į keturis pagrindinius sluoksnius, o virš jų galima pasirinktinai nustatyti telkinio dydį.

Pirmajame sluoksnyje apibrėžiama, kiek išteklių kainuoja vienas darbo vienetas. Antrajame nustatoma, kokį bendrą krūvį vienu metu gali apdoroti eilė arba teikėjų grupė. Trečiajame nurodoma, kiek išteklių gali sunaudoti vienas proceso vykdymas. Ketvirtajame nusprendžiama, ar vykdytojas turėtų iškart pradėti kitą perimtą užduotį, ar atidėti ją, kol dabartinis procesas ir konteineris turės pakankamai laisvų išteklių.

Šie sluoksniai veikia kartu. Apdorojimo komponentas gali nurodyti, kad priklauso brangiai bendrinamai grupei, eilė gali rezervuoti tik ribotą svertinio darbo kiekį vienam teikėjui, darbo eiga gali apriboti, kiek tokio darbo ji pasirengusi sukurti, o vykdytojas vis tiek gali atsisakyti pradėti daugiau tokio darbo, jei dabartinis procesas ar konteineris jau priartėjo prie savo ribų.

Aprašykite vieno darbo vieneto kainą

Užduotys, darbo eigos žingsniai ir būsenos įėjimo veiksmai gali pateikti tas pačias tris išteklių užuominas:

  • concurrency_group
  • concurrency_limit
  • cost_units

concurrency_group ir concurrency_limit aprašo bendrą apkrovą vienai paskesnei sistemai. Jei keli apdorojimo komponentai kreipiasi į tą patį teikėją, API paskyrą ar nuomininką, jie gali naudoti tą pačią grupę, kad vykdytojai vienu metu nepaleistų per daug užduočių.

cost_units aprašo santykinį svorį. Talpyklos atnaujinimas ir didelis kreipinys į teikėją gali abu būti „viena užduotis“, tačiau jie neturėtų būti vertinami vienodai, kai darbo eigos biudžetas ar vykdytojo priėmimo taisyklė sprendžia, ar saugu pradėti daugiau darbo.

PHP
final class CallProviderStep implements \Queuety\Step
{
    public function handle( array $state ): array
    {
        // ...
    }

    public function config(): array
    {
        return [
            'concurrency_group' => 'providers',
            'concurrency_limit' => 3,
            'cost_units' => 5,
        ];
    }
}

Ta pati idėja taikoma išsiunčiamoms užduotims per klasių savybes, o atskiriems išsiuntimams – per PendingJob::concurrency_group() ir PendingJob::cost_units().

Nustatykite bendrinamų eilių ir teikėjų grupių biudžetus

Bendra apkrova ne visada matuojama paprastu vienalaikių užduočių skaičiumi. Kartais didžiausią kainą lemia jau vykdomų užduočių bendras svoris.

Queuety tai užtikrina naudodama svertinius eilių ir grupių biudžetus. Eilių biudžetai nustatomi pagal eilės pavadinimą. Grupės biudžetai nustatomi pagal concurrency_group, todėl nesusiję apdorojimo komponentai gali veikti pagal tą pačią bendrą ribą.

PHP
define( 'QUEUETY_RESOURCE_QUEUE_COST_BUDGETS', [
    'providers' => 20,
    'exports' => 8,
] );

define( 'QUEUETY_RESOURCE_GROUP_COST_BUDGETS', [
    'openai' => 12,
    'tenant:acme' => 6,
] );

Kai vykdytojas perima užduotį, jis peržiūri aktyvias processing eilutes, kurios jau priklauso tai eilei arba grupei. Jei šiuo metu vykdomų užduočių kaina kartu su perimamos užduoties cost_units viršytų sukonfigūruotą biudžetą, vykdytojas grąžina užduotį ir bando dar kartą vėliau.

Tai suteikia kitokį valdymo būdą nei concurrency_limit. Teikėjas gali leisti tris vienalaikes užklausas, bet didesnėms užklausoms rezervuoti mažiau bendrų kainos vienetų nei mažesnėms.

Išlaikykite darbo eigą nustatytose ribose

Darbo eigos biudžetai skirti atvejams, kai problemą kelia ne viena sudėtinga užduotis, o vykdymas, kuris nuolat atranda daugiau darbo, nei numatyta.

Taip dažnai nutinka agentinėse sistemose. Planuoklis gali vėl grįžti prie tos pačios brangios šakos, sukurti per daug antrinių užduočių arba nuolat paleisti antrines darbo eigas, nors formaliai laikomasi įprasto pakartojimų modelio.

Queuety tam suteikia darbo eigos lygmens ribas:

PHP
Queuety::workflow( 'research_run' )
    ->max_transitions( 20 )
    ->max_for_each_items( 12 )
    ->max_state_bytes( 32768 )
    ->max_cost_units( 40 )
    ->max_started_workflows( 8 )
    ->then( PlanResearchStep::class )
    ->for_each( 'tasks', ExecuteResearchTask::class, 'results' )
    ->dispatch();

max_cost_units() neleidžia vykdymui sunaudoti daugiau svertinio darbo, nei numatyta. max_started_workflows() neleidžia tėvinei darbo eigai virsti neribotu aukščiausio lygmens antrinių vykdymų medžiu. Kitos apsaugos priemonės taip pat svarbios, nes ne kiekviena nekontroliuojama darbo eiga yra vienodai brangi.

Darbo eigos būsenoje per viešąjį budget duomenų rinkinį pateikiamos sukonfigūruotos ribos ir dabartinis naudojimas, todėl vykdymą galima stebėti, kol šios ribos galioja.

Leiskite vykdytojams atidėti darbą, kai procesas jau perkrautas

Net jei metaduomenys ir darbo eigos biudžetai sukonfigūruoti tinkamai, galutinį sprendimą vis tiek priima vykdytojo procesas, kuris ketina vykdyti užduotį.

Čia praverčia išteklius įvertinantis priėmimas. Prieš pradedant perimtą užduotį, Queuety gali patikrinti:

  • užduoties bendro vienalaikiškumo grupę
  • svertinius eilės ir teikėjų grupių biudžetus
  • naujausią apdorojimo komponento trukmės ir didžiausio atminties naudojimo istoriją
  • likusį dabartinio vykdytojo atminties rezervą
  • likusį dabartinio konteinerio arba pagrindinio kompiuterio atminties rezervą
  • vienkartinio vykdymo stiliaus paleidimams likusį laiko limitą

Jei vykdytojas jau priartėjo prie sukonfigūruotos ribos, Queuety grąžina užduotį, užuot pradėjęs darbą, kuris greičiausiai nebus sėkmingai užbaigtas.

Šis sprendimas sąmoningai konservatyvus. Tai nėra viso klasterio planuoklis. Tai apsaugos sluoksnis, padedantis apkrautam vykdytojui neperkrauti proceso, kuriame jis veikia, ir, kai prieinami atminties telemetrijos duomenys, jį supančio konteinerio arba pagrindinio kompiuterio.

Konteinerio arba pagrindinio kompiuterio patikra yra pasirenkama. Įjungus QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS, Queuety pirmiausia bando nuskaityti cgroup atminties duomenis, o pagrindiniuose kompiuteriuose su Linux kaip atsarginį variantą naudoja /proc/meminfo. Jei patikimos visos sistemos momentinės nuotraukos gauti nepavyksta, vykdytojas toliau naudoja tik procesui skirtas patikras.

Plėskite vykdytojų grupes nepaisydami pajėgumo ribų

Fiksuotas vykdytojų grupes lengva suprasti, tačiau dėl jų reikia pasirinkti vieną skaičių ir ramiems laikotarpiams, ir apkrovos šuoliams.

Naudodami adaptyvias grupes galite nustatyti minimalią ir maksimalią ribas:

Shell
wp queuety work --queue=providers --min-workers=2 --max-workers=6

Tėvinis procesas išlaiko veikiančius bent minimaliam skaičiui reikalingus antrinius procesus, artėjant užduočių perėmimo eilei prie maksimumo jų skaičių didina, o eilei išbuvus tuščiai nustatytą neveiklumo laikotarpį – mažina.

Pajėgumas vis tiek riboja grupės didinimą. Jei įjungtas sistemos atminties stebėjimas ir tėvinis procesas nemato pakankamai likusios atminties dar vienam visam vykdytojo rezervui, jis išlaiko dabartinį grupės dydį ir nepaleidžia daugiau antrinių procesų.

Realistiškas būdas sujungti sluoksnius

Įsivaizduokite tyrimo darbo eigą, kuri suplanuoja kreipinius į teikėjus, paleidžia specializuotas darbo eigas ir apibendrina rezultatus.

Į teikėją kreipiantis žingsnis gali pateikti cost_units ir bendrinamą concurrency_group, kad keli vykdytojai neužgriūtų to paties modelio teikėjo. Eilė gali rezervuoti svertinį biudžetą šio teikėjo srautui. Tėvinė darbo eiga gali apriboti max_cost_units() ir max_started_workflows(), kad planuoklis negalėtų be galo plėsti vykdymo. Tada vykdytojas vis dar gali atidėti naujai perimtą kreipinį į teikėją, jei naujausi didžiausio atminties naudojimo duomenys rodo, kad procesas arba konteineris jau per arti savo ribos.

Taip gaunami keturi atskiri valdymo būdai:

  1. aprašyti darbo svorį
  2. rezervuoti bendrą eilės arba teikėjo pajėgumą
  3. apriboti, kiek vienas vykdymas gali sukurti
  4. neleisti apkrautam vykdytojui pradėti per daug darbo

Kur rasti išsamią API dokumentaciją

Šiame puslapyje pateikiama konceptuali apžvalga.

Konkrečius parametrus rasite čia:

  • Darbuotojai aprašo priėmimo elgseną ir vykdymo konstantas
  • CLI aprašo fiksuotų ir adaptyvių vykdytojų grupių komandas
  • Darbo eigos apsaugos priemonės aprašo darbo eigos biudžetus
  • Užduotys aprašo užduočių ir apdorojimo komponentų metaduomenis
  • Būsenų automatai aprašo būsenos veiksmų išteklių metaduomenis
  • API pateikia tikslius metodus ir grąžinamų duomenų formas