# Ressursside haldamine

Queuety jagab ressursihalduse neljaks põhikihiks, millele saab lisada valikulise kogumi suuruse määramise.

Esimene kiht kirjeldab ühe tööühiku ressursikulu. Teine piirab, kui suurt jagatud koormust üks järjekord või pakkujarühm võib korraga kanda. Kolmas määrab, kui palju võib üks töövoo käitus tarbida. Neljas otsustab, kas töötaja peaks äsja võetud töö kohe käivitama või lükkama selle edasi, kuni praegusel protsessil ja konteineril on piisavalt vabu ressursse.

Need kihid töötavad koos. Töötleja võib määrata end kalliks jagatud kogumiks, järjekord võib reserveerida ühele pakkujale vaid teatud kaalutud töömahu, töövoog võib piirata loodava sellise töö hulka ning töötaja võib siiski keelduda lisatööd alustamast, kui protsess või konteiner on juba oma piiridele liiga lähedal.

## Kirjeldage ühe tööühiku ressursikulu

Tööd, töövoo sammud ja olekusse sisenemise toimingud saavad kõik määrata samad kolm ressursivihjet:

- `concurrency_group`
- `concurrency_limit`
- `cost_units`

`concurrency_group` ja `concurrency_limit` kirjeldavad jagatud koormust ühele allavoolu süsteemile. Kui mitu töötlejat kasutavad sama pakkujat, API kontot või rentnikku, saavad nad kasutada sama rühma, et töötajad ei käivitaks korraga liiga palju töid.

`cost_units` kirjeldab suhtelist kaalu. Vahemälu värskendamine ja suur pakkujakutse võivad mõlemad olla „üks töö“, kuid töövoo eelarve või töötaja lubamisreegel ei tohiks neid käsitleda võrdsetena, kui otsustatakse, kas lisatöö tegemine on ohutu.

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

Sama põhimõte kehtib väljakutsutavate tööde puhul klassi omaduste kaudu ning üksikute väljasaatmiste puhul atribuutide `PendingJob::concurrency_group()` ja `PendingJob::cost_units()` kaudu.

## Jagatud järjekordade ja pakkujarühmade eelarvestamine

Jagatud koormus ei tähenda alati lihtsalt samaaegsete tööde arvu. Mõnikord on oluline juba käimasolevate tööde kogukaal.

Queuety toetab seda kaalutud järjekorra- ja rühmaeelarvete abil. Järjekorra eelarve võti on järjekorra nimi. Rühma eelarve võti on `concurrency_group`, mis võimaldab eri töötlejatel kasutada sama jagatud ressursipiiri.

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

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

Töö võtmisel vaatab töötaja aktiivseid ridu `processing`, mis kuuluvad juba sellesse järjekorda või rühma. Kui praegu töötava töö kulu koos võetud töö atribuudiga `cost_units` ületaks seadistatud eelarve, vabastab töötaja töö ja proovib hiljem uuesti.

See annab teistsuguse juhtimisvõimaluse kui `concurrency_limit`. Pakkuja võib lubada kolm samaaegset päringut, kuid piirata suurte päringute kogukuluühikuid rohkem kui väikeste omi.

## Hoidke üks töövoog etteantud piirides

Töövoo eelarvetest on abi siis, kui probleem pole ühes raskes töös, vaid käituses, mis avastab pidevalt rohkem tööd, kui ette nähtud.

See on agentsetes süsteemides tavaline. Planeerija võib liikuda korduvalt samasse kulukasse harusse, jagada selle liiga paljudeks alamülesanneteks või jätkata alamate töövoogude käivitamist, püsides samal ajal tehniliselt tavalise korduskatsete mudeli piires.

Queuety pakub selleks töövootaseme piiranguid:

```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()` takistab käitusel kavandatust suurema kaalutud töömahu tarbimist. `max_started_workflows()` takistab vanemtöövoogu muutumast piirituks ülemise taseme alamkäituste puuks. Muud kaitsepiirded on endiselt olulised, sest iga kontrolli alt väljunud töövoog ei ole ühtmoodi kulukas.

Töövoo olek näitab seadistatud piiranguid ja praegust kasutust avaliku `budget` payload’i kaudu, nii et käitust saab nende piirangute kehtimise ajal kontrollida.

## Laske töötajatel tööd edasi lükata, kui protsess on juba liiga koormatud

Isegi kui metaandmete ja töövoo eelarved on hästi seadistatud, teeb lõpliku otsuse siiski tööprotsess, mis hakkab tööd käivitama.

Siin tuleb appi ressursiteadlik vastuvõtmine. Enne kinnitatud töö käivitamist saab Queuety kontrollida:

- töö jagatud samaaegsuskategooriat
- kaalutud järjekorra ja teenusepakkuja rühma eelarveid
- käsitleja hiljutist kestuse ja tippmälu kasutuse ajalugu
- praeguse töötaja vaba mälumahtu
- praeguse konteineri või hosti vaba mälumahtu
- ühekäivituslaadsete käituste jaoks allesjäänud ajalimiiti

Kui töötaja on juba seadistatud ülempiirile liiga lähedal, vabastab Queuety töö selle asemel, et käivitada ülesanne, mis tõenäoliselt korralikult ei lõpe.

Lahendus on meelega konservatiivne. See ei ole täielik klastriplaneerija, vaid ohutuskiht, mis aitab hõivatud töötajal vältida käitatava protsessi ja võimaluse korral ka seda ümbritseva konteineri või hosti ülekoormamist.

Konteineri või hosti jälgimine on valikuline. Kui `QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS` on lubatud, proovib Queuety esmalt lugeda cgroup’i mäluandmeid ja kasutab Linux hostides varuvariandina `/proc/meminfo`. Kui usaldusväärset süsteemitaseme hetkeseisu pole saadaval, jätkab töötaja protsessisiseste kontrollide kasutamist.

## Suurendage töötajate kogumeid võimsust arvestades

Fikseeritud töötajate kogumeid on lihtne mõista, kuid need sunnivad valima ühe arvu nii vaikseteks perioodideks kui ka koormustippudeks.

Kohanduvate kogumite puhul saate määrata hoopis alampiiri ja ülempiiri:

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

Ülemprotsess hoiab töös vähemalt minimaalse arvu alamprotsesse, kasvatab arvu maksimaalse suunas, kui vastuvõetavate tööde järjekord kasvab, ning vähendab seda pärast seadistatud jõudeoleku ooteaja möödumist.

Suurendamisel arvestatakse endiselt saadaolevat võimsust. Kui süsteemimälu jälgimine on lubatud ja ülemprotsess ei näe järgmise töötaja kogu mälumahu jaoks piisavalt vaba mälu, jätab see kogumi praeguse suuruse juurde ega käivita uusi alamprotsesse.

## Kihtide realistlik kombineerimine

Kujutage ette uurimistöövoogu, mis kavandab teenusepakkuja päringuid, käivitab spetsialiseeritud töövooge ja seejärel sünteesib tulemuse.

Teenusepakkujaga suhtlev etapp saab avaldada `cost_units` ja jagatud `concurrency_group`, et mitu töötajat ei koormaks sama mudelipakkujat korraga. Järjekord saab sellele teenusepakkuja liiklusele reserveerida kaalutud eelarve. Ülem-töövoog saab piirata väärtusi `max_cost_units()` ja `max_started_workflows()`, et planeerija ei saaks käitust lõputult kasvatada. Seejärel saab töötaja uue kinnitatud teenusepakkuja päringu edasi lükata, kui hiljutised tippmälu andmed näitavad, et protsess või konteiner on juba ülempiirile liiga lähedal.

Nii saate neli eraldi juhtimisvõimalust:

1. kirjeldage töö kaalu
2. reserveerige jagatud järjekorra või teenusepakkuja võimsust
3. piirake, mida üks käitus võib luua
4. takistage hõivatud töötajal soovitust rohkem tööd käivitamast

## Kust leida üksikasjalikud API-d

See leht annab kontseptuaalse ülevaate.

Üksikasjalikud seaded leiate siit:

- [Workers](https://queuety.inline0.dev/et/docs/features/workers) käsitleb vastuvõtmise käitumist ja käitusaja konstante
- [CLI](https://queuety.inline0.dev/et/docs/cli) käsitleb fikseeritud ja kohanduvate töötajate kogumite käske
- [Workflow Guardrails](https://queuety.inline0.dev/et/docs/workflows/guardrails) käsitleb töövoo eelarveid
- [Jobs](https://queuety.inline0.dev/et/docs/jobs) käsitleb tööde ja käsitlejate metaandmeid
- [State Machines](https://queuety.inline0.dev/et/docs/state-machines) käsitleb olekutoimingute ressursi metaandmeid
- [API](https://queuety.inline0.dev/et/docs/api) loetleb täpsed meetodid ja tagastatavad struktuurid