Preskočiť na obsah

Správa zdrojov

Queuety rozdeľuje riadenie zdrojov do štyroch základných vrstiev a nad ne pridáva voliteľné dimenzovanie fondu.

Prvá vrstva opisuje náročnosť jednej pracovnej jednotky. Druhá obmedzuje, akú záťaž môže naraz znášať jeden front alebo skupina poskytovateľov. Tretia určuje, koľko môže spotrebovať jedno spustenie pracovného postupu. Štvrtá rozhoduje, či má pracovník okamžite spustiť ďalšiu prevzatú úlohu, alebo ju odložiť, kým má aktuálny proces a kontajner dostatočnú rezervu kapacity.

Tieto vrstvy spolupracujú. Obslužná rutina môže deklarovať, že patrí do nákladnej zdieľanej skupiny, front môže vyhradiť poskytovateľovi len určitý objem váženej práce, workflow môže obmedziť množstvo takej práce, ktorú je ochotný vytvoriť, a worker môže stále odmietnuť začať ďalšiu takúto prácu, keď sa aktuálny proces alebo kontajner už príliš približuje k svojim limitom.

Opíšte náklady na jednu jednotku práce

Úlohy, kroky workflow a akcie pri vstupe do stavu môžu zverejniť rovnaké tri informácie o zdrojoch:

  • concurrency_group
  • concurrency_limit
  • cost_units

concurrency_group a concurrency_limit opisujú spoločné zaťaženie jedného nadväzujúceho systému. Ak niekoľko obslužných rutín pristupuje k tomu istému poskytovateľovi, API účtu alebo tenantovi, môžu používať rovnakú skupinu, aby workeri nezačali príliš veľa požiadaviek naraz.

cost_units opisuje relatívnu váhu. Obnovenie vyrovnávacej pamäte a veľké volanie poskytovateľa môžu byť obe „jednou úlohou“, ale pri rozhodovaní o tom, či je bezpečné spustiť ďalšiu prácu, by nemali mať rovnakú váhu v rozpočte workflow ani v pravidle prijímania práce workerom.

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,
        ];
    }
}

Rovnaký princíp platí pre úlohy, ktoré možno odoslať, prostredníctvom vlastností triedy, a pre jednotlivé odoslania prostredníctvom PendingJob::concurrency_group() a PendingJob::cost_units().

Nastavte rozpočty zdieľaných frontov a skupín poskytovateľov

Spoločné zaťaženie sa nie vždy týka jednoduchého počtu súbežných úloh. Niekedy sú nákladné najmä kombinované nároky už prebiehajúcich úloh.

Queuety to podporuje pomocou vážených rozpočtov frontov a skupín. Rozpočty frontov sa určujú podľa názvu frontu. Rozpočty skupín sa určujú podľa concurrency_group, vďaka čomu sa môžu nesúvisiace obslužné rutiny zapojiť do rovnakého spoločného limitu.

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

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

Keď worker prevezme úlohu, pozrie sa na aktívne záznamy processing, ktoré už patria do daného frontu alebo skupiny. Ak by súčet nákladov aktuálne vykonávanej práce a cost_units prevzatej úlohy prekročil nastavený rozpočet, worker úlohu uvoľní a skúsi to znova neskôr.

To vám poskytuje inú možnosť riadenia než concurrency_limit. Poskytovateľ môže povoliť tri súbežné požiadavky a zároveň vyhradiť menej celkových nákladových jednotiek na väčšie požiadavky než na menšie.

Udržte jeden workflow v stanovených medziach

Rozpočty workflow sú určené pre prípady, keď problém nespočíva v jednej náročnej úlohe, ale v behu, ktorý neustále objavuje viac práce, než sa zamýšľalo.

To je bežné v agentových systémoch. Plánovač môže opakovane prechádzať tou istou nákladnou vetvou, rozdeliť ju na priveľa podúloh alebo stále spúšťať podriadené workflow, pričom formálne dodržiava bežný model opakovania.

Queuety na tento účel poskytuje limity na úrovni workflow:

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() zabraňuje tomu, aby beh spotreboval viac váženej práce, než sa zamýšľalo. max_started_workflows() bráni nadradenému behu vytvoriť neobmedzený strom nadradených behov potomkov. Ostatné ochranné opatrenia sú stále dôležité, pretože nie každý nekontrolovaný workflow je nákladný rovnakým spôsobom.

Stav workflow zverejňuje nastavené limity a aktuálnu spotrebu prostredníctvom verejného objektu budget, takže beh možno kontrolovať, kým sú tieto limity aktívne.

Umožnite workerom odložiť prácu, keď je proces už príliš vyťažený

Aj keď sú metadáta a rozpočty workflow dobre nastavené, konečné rozhodnutie stále prináleží procesu workera, ktorý sa chystá vykonať úlohu.

Tu prichádza na rad prijímanie práce s ohľadom na zdroje. Pred spustením prevzatej úlohy môže Queuety skontrolovať:

  • zdieľanú skupinu súbežnosti danej úlohy
  • vážené rozpočty frontu a skupiny poskytovateľov
  • nedávne trvanie a históriu špičkovej spotreby pamäte obslužnej rutiny
  • zostávajúcu pamäťovú rezervu aktuálneho workera
  • zostávajúcu pamäťovú rezervu aktuálneho kontajnera alebo hostiteľa
  • zostávajúci časový limit pre jednorazové behy

Ak sa worker už príliš približuje k nastavenému limitu, Queuety úlohu uvoľní namiesto spustenia práce, ktorá sa pravdepodobne nedokončí bez problémov.

Tento mechanizmus je zámerne konzervatívny. Nejde o plnohodnotný plánovač klastra. Je to bezpečnostná vrstva, ktorá pomáha vyťaženému workeru predísť nadmernému zaťaženiu procesu, v ktorom beží, a v prípade dostupnej telemetrie pamäte aj kontajnera alebo hostiteľa, na ktorom je spustený.

Kontrola kontajnera alebo hostiteľa je voliteľná. Keď je povolené QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS, Queuety sa najprv pokúsi načítať údaje o pamäti cgroup a na hostiteľoch Linux potom použije /proc/meminfo. Ak nie je k dispozícii spoľahlivý systémový snímok, worker naďalej používa lokálne kontroly procesu.

Škálujte skupiny workerov s ohľadom na kapacitu

Pevne nastavené skupiny workerov sa ľahko pochopiteľne nastavujú, no zároveň vás nútia vybrať jedno číslo pre obdobia pokoja aj náporu.

Adaptívne skupiny vám namiesto toho umožňujú nastaviť minimum a maximum:

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

Nadradený proces udržiava aktívny aspoň minimálny počet potomkov, pri narastaní čakajúcich úloh, ktoré možno prevziať, sa rozrastá až po maximum a po uplynutí nastavenej ochrannej lehoty nečinnosti frontu sa opäť zmenší.

Zväčšovanie skupiny stále zohľadňuje dostupnú kapacitu. Ak je povolené sledovanie systémovej pamäte a nadradený proces nevidí dostatok voľnej pamäte pre ďalšieho workera s plným limitom zdrojov, ponechá skupinu na aktuálnej veľkosti namiesto spustenia ďalších potomkov.

Realistický príklad kombinácie vrstiev

Predstavte si výskumný workflow, ktorý plánuje volania poskytovateľa, spúšťa špecializované workflow a potom syntetizuje výsledok.

Krok komunikujúci s poskytovateľom môže zverejniť cost_units a zdieľaný concurrency_group, aby viacerí workeri nezaťažili naraz toho istého poskytovateľa modelu. Front môže pre túto komunikáciu s poskytovateľom vyhradiť vážený rozpočet. Nadradený workflow môže obmedziť max_cost_units() a max_started_workflows(), aby plánovač nemohol donekonečna rozširovať beh. Worker potom môže odložiť aj novú prevzatú požiadavku poskytovateľovi, ak údaje o nedávnej špičkovej spotrebe pamäte ukazujú, že proces alebo kontajner sa už príliš približuje k svojmu limitu.

Získate tak štyri samostatné možnosti riadenia:

  1. opísať váhu práce
  2. vyhradiť kapacitu zdieľaného frontu alebo poskytovateľa
  3. obmedziť, koľko môže jeden beh vytvoriť
  4. zabrániť vyťaženému workeru spustiť viac práce, než by mal

Kde nájdete podrobné API

Táto stránka poskytuje koncepčný prehľad.

Konkrétne nastavenia nájdete tu:

  • Workeri opisuje správanie pri prijímaní práce a konštanty prostredia
  • CLI opisuje príkazy pre pevné a adaptívne skupiny workerov
  • Ochranné opatrenia workflow opisuje rozpočty workflow
  • Úlohy opisuje metadáta úloh a obslužných rutín
  • Stavové automaty opisuje metadáta zdrojov akcií stavov
  • API uvádza konkrétne metódy a tvary návratových hodnôt