Řešení 1:
Ne jistě, ale většinou na 1.00*n_cpu .
Zátěž znamená následující:pokud je na systému s jedním procesorem více procesů, běží zdánlivě paralelně. Ale není to pravda. Co se prakticky stane:jádro dá procesu 1/100 sekundy a pak přeruší jeho běh přerušením. A dá další 1/100 sekundy jinému procesu.
Prakticky otázka, "který proces by měl dostat náš další interval 1/100 sekundy?", bude rozhodnuta složitou heuristiky. Jmenuje se jako úkol plánování .
Procesy, které jsou blokovány, například čekají na svá data, co čtou z disku, jsou samozřejmě z tohoto plánování úloh vyjmuty.
Co říká zatížení:kolik procesů aktuálně čeká na další časový rámec 1/100 sekundy. Samozřejmě jde o střední hodnotu. Je to proto, že v cat /proc/loadavg můžete vidět více čísel .
Situace v systému s více procesory je trochu složitější. Existuje více procesorů, jejichž časové rámce mohou být přiděleny více procesům. To dělá plánování úkolů trochu - ale ne příliš - složitější. Ale situace je stejná.
Jádro je inteligentní, snaží se sdílet systémové prostředky pro optimální efektivitu a tomu se blíží (jsou tam drobné optimalizační věci, například je lepší, když bude proces běžet co nejdelší dobu na stejném cpu kvůli úvahám o ukládání do mezipaměti, ale na tom nezáleží). Je to proto, že pokud máme zatížení 8, znamená to:ve skutečnosti čeká na svůj další časový úsek 8 procesů. Pokud máme 8 procesorů, můžeme dát tyto časové úseky procesoru jedna ku jedné, a náš systém tak bude optimálně využit.
Pokud vidíte top , můžete vidět, že počet aktuálně běžících procesů je překvapivě nízký:jsou to procesy označené R tam. I na ne zcela hardcore systému je často pod 5. Částečně je to proto, že procesy čekající na svá data z disků nebo ze sítě jsou také pozastaveny (označeno S nahoře). Zátěž ukazuje pouze využití procesoru.
Existují nástroje na měření zátěže disku, imho by měly být důležité minimálně jako sledování využití procesoru, ale v našem profesionálním sysadminském světě to nějak není tak známé.
Nástroje Windows často rozdělují zátěž podle skutečného počtu procesoru. To způsobuje, že někteří profesionální správci systému Windows používají zatížení systému v tomto smyslu rozděleném podle CPU. Nemají pravdu a budou pravděpodobně šťastnější, až jim to vysvětlíte.
Vícejádrové CPU jsou prakticky více CPU na stejném křemíkovém čipu. Není v tom žádný rozdíl.
V případě procesorů s hypervláknem existuje zajímavý vedlejší efekt:načítání procesoru zpomaluje jeho páry s hypervláknem. Ale to se děje na hlubší vrstvě, kterou zvládá normální plánování úloh, i když to může (a mělo by) ovlivnit rozhodnutí plánovače o pohybu procesu.
Ale z našeho současného pohledu – co určuje zatížení systému – na tom také nezáleží.
Řešení 2:
Průměrná zátěž neznamená to, co si myslíte. Nejde o okamžité využití procesoru, ale spíše o to, kolik procesů čeká na spuštění. Obvykle je to proto, že spousta věcí chce CPU, ale ne vždy. Častým viníkem je proces čekající na IO – disk nebo síť.
Zkuste spustit ps -e v a hledá příznaky stavu procesu.
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process:
D Marks a process in disk (or other short term, uninterruptible) wait.
I Marks a process that is idle (sleeping for longer than about 20 seconds).
L Marks a process that is waiting to acquire a lock.
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20 seconds.
T Marks a stopped process.
W Marks an idle interrupt thread.
Z Marks a dead process (a "zombie").
Toto je z ps manuálovou stránku, takže tam najdete další podrobnosti - R a D procesy jsou pravděpodobně zvláště zajímavé.
Můžete skončit s průměrnými „špičkami“ zátěže z nejrůznějších důvodů, takže ve skutečnosti nejsou dobrým měřítkem ničeho jiného než „je tento systém zaneprázdněn“. Zabřednutí do mapování průměrné zátěže na jádra CPU vám nic dobrého nepřinese.
Řešení 3:
Vzhledem k tomu, že hyperthreading není ve skutečnosti 2. jádro, nikdy nevybere jádro na 200 %, ale u určitých pracovních zátěží to překročí 100 %.
Vaše maximální zatížení je tedy někde neznámé mezi přibližně 4 a 6
(samozřejmě to může být vyšší při přetížení, protože ve skutečnosti počítá spustitelné procesy, zvláště když čekají na IO)
Řešení 4:
Na linuxovém systému se pro výpočet zatížení započítávají nejen procesy ve spustitelné frontě, ale také ty, které jsou ve stavu nepřerušitelného spánku, wikipedie, což způsobuje, že zatížení stoupá, když máte spoustu procesů čekajících na disk.
Řešení 5:
Udělal jsem nějaké experimenty na našem 24jádrovém systému Xeon (2 socket x 12 jader). Maximální zatížení je v tomto případě 48.0 kvůli způsobu, jakým Linux nastavuje hyperthreading.
Nedostanete však ekvivalent 48 jader propustnosti. Všiml jsem si, že v prvních 24 logických procesorech získáte asi 90% propustnosti, tj. pokud zatížení běží na 24.0. Pak získáte další propustnost asi 10 % pro zbývajících 24 logických procesorů (zatížení běží na 48,0). Dalším způsobem, jak o tom přemýšlet, je, že pokud na 24 jádrech spustíte 48 vláken, získáte zvýšení asi o 10–20 %, pokud povolíte hyperthreading oproti ne. Není to 100% podpora, jak by naznačovali lidé z marketingu.
Například jedním ze způsobů testování tohoto pozorování je mít proces, který spouští 48 vláken (řekněme pomocí TBB nebo model ručního vytváření vláken), a poté spustit
time numactl --physcpubind=0-23 ./myprocess
a poté spusťte
time numactl --physcpubind=0-47 ./myprocess
Ten by měl běžet asi o 10-20% kratší dobu. Pokud je váš proces silně blokován I/O, může být výsledek jiný.
První z nich zakáže hyperthreading tím, že umožní vláknům běžet pouze na jediném logickém procesoru (každého jádra), zatímco druhý umožní hyperthreading tím, že umožní vláknům běžet na 2 logických procesorech (každého jádra).
Zátěž v obou případech by měla být hlášena jako 48,0 ... což, jak vidíte, je velmi zavádějící.