Správa procesů - omezení počtu zároveň běžících procesů

[zabak]

Admin rozhraní by mělo umožňovat nastavení limitu paralelně běžících procesů a zajistit dodržování tohoto limitu. Jádro Krameria by mohlo zjistit, jaké množství CPU jader má k dispozici a podle toho doporučit a přednastavit vhodný horní limit počtu procesů, admin by měl mít možnost tuto hodnotu změnit na cokoli mezi 1 a touto horní hranicí. V současnosti když pošlu například větší dávku uuid na změnu viditelnosti včetně potomků, tak se to celé navzájem zaseká a ty procesy trvají hrozně dlouho. Není řešením dávat to tam po několika uuid a čekat až se to dokončí, to popírá smysl automatizace, často potřebujeme měnit stovky, někdy i tisíce objektů najednou.

[pavel-stastny]

@zabak Pocet procesů jde měnit proměnnou processQueue.activeProcess , plánovaná změna je, že se bude respektovat nebo prioritizovat to co je v rámci jedné dávky (tak aby první doběhla již rozběhnutá dávka a pak teprve další).

Ohledně plánování procesů dle jader apod. Nebude naopak v budoucnu požadavek aby se procesy řešily prostředky kubernetes? (Aby šlo s procesy hýbat v rámci klustru ?)

[VerosK]

Není dobrý nápad učit Krameria, aby se přizpůsoboval CPU loadu stroje na kterém běží. Pokud běží někde v kontejnerech či K8S, tak na stroji může běžet i jiná zátěž a Kramerius by zbytečně stál. Navíc zjišťovat CPU load je poměrně nespolehlivé.

Za mne ideální řešení by bylo mít možnost spustit Kramerius API server (jádro) tak, aby buď servírovalo API, nebo aby běželo na pozadí jako "pracant / worker", který bude spouštět procesy.

Pokud poběží v režimu "pracant", chtěl bych mít možnost nastavit Krameriovi, kolik procesů paralelně může spustit vedle sebe. A chtěl bych mít možnost nastavit mu, že po zpracování N procesů má skončit, nebo má běžet trvale a pokud procesy mít nebude, tak usne a bude čekat.

Velmiby se mi hodilo mít možnost zvenku zjistit metriku: "Počet procesů, které čekají na spuštění", třeba přes nějaké Prometheus API.

Pokud bude k dispozici tohle, tak jsme schopni pokrýt různé druhy nasazení:

• jedna instance pro malou instituci - Kramerius poběží jako API i worker najdnou.
• oddělené instance pro větší instituce - uživatelé budou chodit na jednu instanci s API a na pozadí bude několik trvalých workerů, kteří budou pracovat. Pracanti neovlivní odezvu pro uživatele
• škálované instance v MZK a NK - dvě API instance pro uživatele + budeme mít možnost dynamicky spouštět omezený počet pracantů podle toho, kolik je k dispozici CPU a kolik práce se musí udělat.

[vlahoda]

Verosi, s tou metrikou "pocet procesu, co ckaji na spusteni" je to urcite zajimavy a uzitecny napad, ale myslim, ze ten zakladni problem, co se tu diskutuje, bude k vseobecne spokojenosti vyresen tim, co zminoval Pavel S, tedy prioritizaci dcerinnych procesu v ramci jedne davky.