Dotaz: kdy zacina byt jeden core vytizeny na 100% problem?

[chtel_bych_se_zeptat]

Dobry den vsem,

na zaklade tohoto clanku: https://medium.com/netflix-techblog/linux-performance-analysis-in-60-000-milliseconds-accc10403c55 jsem si do nedavna zrejme mylne myslel ze vyuziti jednoho core na 100% muze by problem.

Nasadil jsem nejake checkovaci skripty, kdy z /proc/stat v pravidelnych intervalech pocitam prumernou utilizaci pro vsechny CPU a dale pak utilizaci pro jednotliva CPU(chcete-li core). Z vysledku jsem zjistil ze na cca 1/3 vsech serveru si obcas nejake jedno CPU poskoci na 100% v kratkem peaku (nekdy treba jen par sekund) a pak se vrati do normalu. Pritom prumerna utilizace vsech CPU zustava relativne nizka. Takze monitorovani utilizace core per core jsem prozatim ponechal, ale pokud jeden vyskoci nad 100%, neberu to jako warning.

Po precteni tohoto https://unix.stackexchange.com/a/276244 si nyni myslim ze vyuziti core na 100% muze byt a jistych okolnosti dokonce uzitecne - ciste vypocetni aplikace, i kdyz se domnivam ze takovych moc neprovozujeme (Nepocitame stari vesmiru, ani pravdepodobnost stretu s proletajicim asteroidem).

Nicmene me to odkazuje zpet na prvni clanek. Kdy zjistim ze vytizene CPU na 100% je problem - predpokladam, ze je to situace kdy toto CPU zatezuje jedno threadova aplikace a vypocetni vykon zatezovaneho CPU ji nestaci. V pripade ze si aplikace ke svoji praci forkuje procesy, tak myslim ze budou stat ve fronte a zacne rust load.

Takze teoreticky, v pripade ze mam v systemu 4 core a jen jeden je vyutizen na 100%. Kdy muzu predpokladat ze mam problem. Az se stoupajicim loadem a neklesajici utilizaci vytizeneho core?

V pripade ze by jste nekdo mel odkaz na nejaky hezky clanek, nejlepe v cestine, tak budu moc rad.

Predem diky za odpovedi.

Odpovědi

[OldFrog {Ondra Nemecek}]

v systemu 4 core a jen jeden je vytizen na 100%

Krátkodobě to je běžná věc.

Dlouhodobě to je problém snad pouze pokud platíte za využití CPU nebo pokud máte špatné chlazení.

Ale může to signalizovat, že se daný proces zacyklil a neodvádí reálnou práci, kterou po něm chcete. To samozřejmě problém je.

Server má být co nejvíce vytížený, pokud po něm chcete nějakou práci. Optimálního vytížení dosáhnete vybalancováním zatížení CPU, vstupně výstupních operací a využití paměti. Tím dosáhnete optimální propustnosti a nižšího loadu. Vyšší load ale nemusí být ještě nutně problém, je to spíš sekundární ukazatel.

Je spousta úloh, kde je 100% vytížení dokonce všech jader CPU žádoucí - zpracování videa, obrázků, zvuku, kompilace, komprese, deduplikace, zpracování statistik, umělá iteligence...

[k3dAR]

... kdyz mas singlecore CPU

[Michal Kubeček]

Především je potřeba si uvědomit, že pokud proces "něco dělá" (ve smyslu zátěže CPU), je naprosto normální a žádoucí, že zatěžuje procesor naplno (pokud se o něj nemusí dělit s někým dalším). Není-li tomu tak, znamená to, že část času na někoho nebo na něco čeká (např. vstup od uživatele, data ze sítě, hardware, zámky nebo jiné zdroje).

Z jiného úhlu pohledu to ale také znamená, že proces je limitován procesorem, takže s rychlejším procesorem by mohl běžet rychleji. A pokud zatěžuje jenom jedno jádro naplno, zatímco ostatní jsou volná, mohl by fungovat efektivněji, kdyby byl program přepsaný tak, aby zátěž uměl rozložit mezi více (logických) CPU - což ale ne u každé úlohy jde a i když to jde, nemusí to být jednoduché.

Takže první otázka, kterou byste si měl položit, když takový stav vidíte, je jestli je očekávané a správné, že daný proces v danou chvíli zatěžuje procesor. Pokud ne, pak se ptát proč se tak děje. Pokud ano, tak jestli je pro vás ten program "dost rychlý" nebo jestli je pro vás to omezení procesorem problém.

[debian+]

Znacis si, aj na akych frefrenciach ti bezi procak, ci si im dal vsetkym pevnu hodnotu? Lebo 100% 800MHz je 50% 1600MHz pri takte jadra.

[chtel_bych_se_zeptat]

Vsechny maj stejnou "by default" hodnotu - jsou to virtualky poskytnute dodavatelem. (Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz)

[jiwopene]

Ve virtuálkách se procesor také zpomaluje podle zátěže.

[M. Ponkrác]

A kde má být problém?

[chtel_bych_se_zeptat]

Nerozumim, ostatni uzivatele pred Vami pochopili na co se ptam...

Ptam se jak poznat ze 100% vytizeni jednoho CPU na serveru ktery ma 4 CPU je, nebo neni problem. Kdy si muzu rict, aha ted to pracuje idealne a ted uz to jedno CPU nestiha - v pripade jedno threadove aplikace...

[MadCatX]

Já tomu tedy moc nerozumím taky. Tohle totiž záleží na charakteru aplikace. Nějaký výpočetní program CPU vytíží naplno vždycky. Poskytneš-li mu rychlejší CPU, vytíží ho taky, akorát ten výpočet doběhne dříve. Na druhou stranu plně zatížený webový server už by mohl být problematický; doba odezvy by mohla být vyšší, než jsou uživatelé ochotní akceptovat, některé požadavky by mohly vytimeoutovat apod. První je třeba si říci, co považuješ za "problém" a až pak uvažovat, zda lze 100 % load na jednom CPU považovat za nežádoucí.

[Michal Kubeček]

Někdy je to dokonce naopak: má-li být úloha CPU bound a procesor není zatížen (téměř) naplno, je to signál, že něco není v pořádku. Budu-li třeba překládat nějaký větší projekt (jádro, Firefox, LibreOffice, …) na stroji s dostatkem procesorů, ale s pracovním adresářem na disku (a zejména na klasickém disku), může se snadno stát, že procesory nebudou zdaleka vytížené, protože příliš velkou část času se bude čekat na disk. (Takže je pak lepší takový překlad dělat na tmpfs.)

[Aleš Kapica]

Problém je to tehdy, když ti ho na 100% vytěžuje aplikce u níž to není normální. Kupř. browser, je-li vše ok, by 100% CPU nikdy neměl žrát.

Za určitých okolností to může být také indikátor, že je někde něco špatně. Kupř. kdysi jsem na základě toho zjistil, že nám na síti udělali smyčku – jeden virtuální switch "vařil" na 100%, takže jsem ihned věděl kde hledat problém.

[Peter Golis]

Zrovna pri browseri je to bežné chovanie. Stránky si bez problémov nasyslia JS ktorý ráta kadejaké kryptokoniny aby zarobili ešte viac. Dosť humorné je to keď ten JS začne variť CPU po nejakom čase, aby to nebolo nápadné.

[j]

Blbe se ptas ... existuje cely spektrum situaci, od "neni to problem vubec zadnej" az po "je to pruser".

Pokud ti jde o ten HW, tak to problem neni zadnej, ten HW to da, navic kazdej system prubezne vicejadra rotuje = ulohu prehazuje.

Pokud jde o celkovej beh toho systemu, tak to zalezi na milionu ruznych aspektu, takze se ti neda odpovedet. Na tuxovi bejva zvykem sledovat spis load nez utilization. Jednoduse proto, ze narozdil od widli ho jedno zatizeny jadro neprivede do nemy smrti.

Ale pokud ta konkretni uloha trebas nejak s necim komunikuje, muze to byt pruser proto, ze nestiha reagovat v ramci timeoutu a pod.

V kazdym pripade je to vec, ktera stoji za prozkoumani na tema co to je, co to dela, proc to dela, musi to delat zrovna takhle .... protoze jak tu uz ruzne zaznelo, pak mozna zjistis, ze ta uloha muze bezet na 20 jadrech 1/10 casu, nebo ze muze bezet na jednom jadre a brat si z nej 10%, protoze je tam neco vyrazne blbe ...

Jestli chces krasnej priklad to ho "je tam neco vyrazne blbe" tak opet ze sveta widli. Vyzkousejte si to. w10, aktualizace, optimalne "hodne" aktualizaci (projevi se to razantnejs). Ta vec (settins/nastaveni) co zobrazuje seznam aktualzaci a % jejich stazenosti/nainstalovanosti ... s klidem sezere i 50% vykonu CPU... sama o sobe. Staci klipnout na instalaci, Chvilu pockat (cpu vyleti na 80+%) a pak to okno zavrit. Stahuje a instaluje se dal ... jen uz to zere "jen" 10-20% ... (a je to i rychlejsi, instalace se zavrenym oknem trva klidne o 1/3 casu min, overeno na totoznym HW).

[qwe]

může to být problém nebo to může být žádoucí. záleží na programu, takhle obecně se nedá odpovědět.

[JuraJurator]

Ahoj všichni,

Jak tedy zjistím zda 100% vytížení procesuru je u dané aplikace problém ? Napadá mě např #top #Free a sledovat zda to swapuje či jiné parametry ? Díky předem za nápady. Předem díky za nápady. Jura

[Max]

Jednoduše tak, že ti nebude vyhovovat chování té konkrétní aplikace (pomalost, špatné odezvy atd.).
Jediné řešení je znát prostředí, znát aplikaci a vědět, co je ještě ok a co už je za hranou.
Zdar Max