Upravljanje virov

Queuety razdeli nadzor nad viri na štiri osnovne plasti, nad katerimi je še neobvezno določanje velikosti skupin.

Prva plast opisuje strošek ene delovne enote. Druga omejuje skupno obremenitev, ki jo lahko hkrati nosi ena čakalna vrsta ali skupina ponudnikov. Tretja določa, koliko lahko porabi posamezen zagon poteka dela. Četrta odloča, ali naj delavec takoj začne naslednje prevzeto opravilo ali ga odloži, dokler je v trenutnem procesu in vsebniku še dovolj rezerve.

Te plasti delujejo skupaj. Obravnavalnik lahko določi, da spada v skupno skupino z visokimi stroški, čakalna vrsta lahko omeji količino uteženega dela za enega ponudnika, potek dela lahko omeji količino takega dela, ki ga je pripravljen ustvariti, delavec pa lahko še vedno zavrne začetek dodatnega dela, če sta trenutni proces ali vsebnik že blizu omejitev.

Opišite strošek ene delovne enote

Opravila, koraki poteka dela in dejanja ob vnosu stanja lahko objavijo iste tri namige o virih:

• concurrency_group
• concurrency_limit
• cost_units

concurrency_group in concurrency_limit opisujeta skupno obremenitev enega nadaljnjega sistema. Če več obravnavalnikov dostopa do istega ponudnika, računa API ali najemnika, lahko uporabijo isto skupino, da delavci ne začnejo preveč opravil hkrati.

cost_units opisuje relativno težo. Osvežitev predpomnilnika in velik klic ponudnika sta lahko oba »eno opravilo«, vendar pri odločanju, ali je varno ustvariti še več dela, ne bi smela enako vplivati na proračun poteka dela ali pravilo sprejema delavcev.

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

Ista zamisel velja za opravila, ki jih je mogoče odpremljati, prek lastnosti razreda, in za posamezne odpreme prek PendingJob::concurrency_group() in PendingJob::cost_units().

Določite proračune za skupne čakalne vrste in skupine ponudnikov

Skupna obremenitev ni vedno odvisna le od števila sočasnih opravil. Včasih je draga skupna utež že izvajanih opravil.

Queuety to podpira z uteženimi proračuni čakalnih vrst in skupin. Proračuni čakalnih vrst so določeni z imenom čakalne vrste. Proračuni skupin so določeni z concurrency_group, kar omogoča nepovezanim obravnavalnikom, da si delijo isto skupno omejitev.

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

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

Ko delavec prevzame opravilo, preveri aktivne vrstice processing, ki že pripadajo tej čakalni vrsti ali skupini. Če bi trenutni strošek skupaj z cost_units prevzetega opravila presegel nastavljeni proračun, delavec opravilo sprosti in ga poskusi znova pozneje.

To omogoča drugačno uravnavanje kot concurrency_limit. Ponudnik lahko dovoli tri sočasne zahteve, vendar za večje zahteve nameni manj skupnih stroškovnih enot kot za manjše.

Omejite posamezen potek dela znotraj določenih meja

Proračuni potekov dela so namenjeni primerom, ko težava ni eno zahtevno opravilo, temveč zagon, ki nenehno odkriva več dela, kot je bilo predvideno.

To je pogosto v agentnih sistemih. Načrtovalnik lahko večkrat obišče isto drago vejo, jo razdeli na preveč podopravil ali še naprej zaganja podrejene poteke dela, čeprav je še vedno znotraj običajnega modela ponovnih poskusov.

Queuety za to zagotavlja omejitve na ravni poteka dela:

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() preprečuje, da bi zagon porabil več uteženega dela, kot je predvideno. max_started_workflows() preprečuje, da bi se nadrejeni potek spremenil v neomejeno drevo vrhnjih podrejenih zagonov. Druga varovala so še vedno pomembna, saj vsi ubežni poteki dela niso enako zahtevni.

Stanje poteka dela prek javnega tovora budget razkriva nastavljene omejitve in trenutno porabo, zato je izvajanje mogoče nadzorovati, dokler so te omejitve aktivne.

Omogočite delavcem, da odložijo delo, ko je proces že preobremenjen

Tudi če so metapodatki in proračuni potekov dela dobro nastavljeni, je končna odločitev še vedno v rokah procesa delavca, ki bo izvedel opravilo.

Tu nastopi sprejemanje, ki upošteva vire. Pred začetkom prevzetega opravila lahko Queuety preveri:

• skupino sočasnosti, ki si jo opravilo deli z drugimi
• utežene proračune za čakalno vrsto in skupine ponudnikov
• nedavno trajanje in najvišjo porabo pomnilnika za obravnavalnik
• preostalo pomnilniško rezervo trenutnega delavca
• preostalo pomnilniško rezervo trenutnega vsebnika ali gostitelja
• preostali časovni okvir za enkratna izvajanja

Če je delavec že preblizu nastavljene zgornje meje, Queuety sprosti opravilo, namesto da bi začel delo, ki se verjetno ne bo uspešno zaključilo.

Ta pristop je namenoma konservativen. Ne gre za poln razporejevalnik gruče, temveč za varnostno plast, ki pomaga zasedenemu delavcu preprečiti preobremenitev procesa, v katerem se izvaja, in ob razpoložljivih podatkih o pomnilniku tudi vsebnika ali gostitelja, ki ga obdaja.

Del za vsebnik ali gostitelja je neobvezen. Ko je QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS omogočen, Queuety najprej poskusi prebrati podatke o pomnilniku cgroup, nato pa na gostiteljih Linux uporabi /proc/meminfo. Če zanesljiv sistemski posnetek ni na voljo, delavec še naprej uporablja preverjanja na ravni procesa.

Razširite skupine delavcev, ne da bi prezrli zmogljivost

Fiksne skupine delavcev je preprosto razumeti, vendar vas prisilijo, da izberete eno število tako za mirna obdobja kot za konice obremenitve.

Prilagodljive skupine vam namesto tega omogočajo nastaviti spodnjo in zgornjo mejo:

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

Nadrejeni proces skrbi, da je vedno aktivno vsaj najmanjše število podrejenih procesov, povečuje njihovo število do največjega, ko se poveča zaostanek opravil, ki jih je mogoče prevzeti, nato pa skupino zmanjša, ko je čakalna vrsta tiha toliko časa, kot določa nastavljeno obdobje mirovanja.

Povečevanje števila delavcev še vedno upošteva razpoložljive zmogljivosti. Če je omogočeno upoštevanje sistemskega pomnilnika in nadrejeni proces ne zazna dovolj preostalega pomnilnika za celoten obseg še enega delavca, ohrani trenutno velikost skupine, namesto da bi zagnal dodatne podrejene procese.

Praktičen način kombiniranja plasti

Predstavljajte si raziskovalni potek dela, ki načrtuje klice ponudnikov, zažene specializirane poteke dela in nato združi rezultate.

Korak, ki komunicira s ponudnikom, lahko objavi cost_units in skupni concurrency_group, da več delavcev hkrati ne bi preobremenilo istega ponudnika modela. Čakalna vrsta lahko za promet tega ponudnika rezervira uteženi proračun. Nadrejeni potek dela lahko omeji max_cost_units() in max_started_workflows(), da načrtovalnik ne more neskončno povečevati izvajanja. Delavec lahko nato še vedno odloži na novo prevzeti klic ponudnika, če nedavni podatki o najvišji porabi pomnilnika kažejo, da sta proces ali vsebnik že preblizu zgornje meje.

Tako dobite štiri ločene načine nadzora:

1. opišite utež opravila
2. rezervirajte skupno zmogljivost čakalne vrste ali ponudnika
3. omejite, kaj lahko ustvari posamezno izvajanje
4. preprečite, da bi zaseden delavec začel preveč dela

Kje najdete podrobne API-je

Ta stran je konceptualni pregled.

Za konkretne nastavitve:

• Delavci opisuje vedenje pri sprejemanju in konstante med izvajanjem
• CLI opisuje ukaze za fiksne in prilagodljive skupine delavcev
• Varovala poteka dela opisujejo proračune poteka dela
• Opravila opisujejo metapodatke opravil in obravnavalnikov
• Stroji stanj opisujejo metapodatke o virih za dejanja stanj
• API navaja natančne metode in oblike vrnjenih vrednosti