Pokud jde o odstraňování problémů s výkonem v Linuxu, je velmi důležité znát základy různých výstupů příkazů, jako je uptime, vmstat. V tomto příspěvku se pokusíme porozumět průměrům zatížení a spustit frontu/blokovanou frontu z hlediska využití CPU. Nejprve si vysvětlíme, co je to Průměrná zátěž:
Průměrná zátěž je počet úloh ve frontě běhu (stav R) nebo čekajících na diskový I/O (stav D) v průměru za 1, 5 a 15 minut. Příklad výstupu z příkazu uptime/top:
# uptime 11:49:14 up 25 days, 5:56, 68 users, load average: 0.03, 0.13, 0.47
# top -b -n 1 top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached
Základní pravidlo zní:
- Jednojádrový systém – pokud je průměr zátěže 1,00, znamená to, že systém je plně vytížen a pokud bude přicházet více úloh, budou zařazeny do fronty a budou čekat na provedení.
- Jednojádrový systém – pokud je průměr zatížení 2,00, znamená to, že systém je již využíván a některé úlohy jsou již zařazeny do fronty a čekají na provedení.
- Vícejádrový systém (4 jádra) – pokud je průměr zatížení 1,00, znamená to, že systém využívá 1/4 jeho možností CPU, jedna úloha je aktivně spuštěna a stále jsou 3 jádra ve fázi „nečinnosti“.
- Vícejádrový systém (4 jádra) – pokud je průměr zátěže 4,00, znamená to, že systém využívá všechna 4 jádra a znamená to, že systém je plně využit.
Zbývá ve výše uvedených případech ještě nějaký prostor? – obvykle ne – pokud se průměrná zátěž blíží počtu jader v systému – OS by měl být zkontrolován, aby se zjistilo skutečné úzké hrdlo a chybějící ladění nebo možná OS není správně škálován tak, aby obsluhoval úkoly APP/DB.
Jak se počítá průměrná hodnota zatížení na aktivním OS? – k tomu potřebujeme najít run queue, která je dostupná přes příkaz vmstat:
Nečinný systém (8jádrový systém)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 0 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 0 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
Aktivní systém (8jádrový systém)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 7 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 2 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 6 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 1 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 8 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
Výše uvedené výstupy jsou příklady – první ukazuje, že aktuální fronta běhu (r) je 0, kde fronta běhu aktivního systému skáče z 1 na 8 v 6 sondách.
Co přesně je run queue?
run-fronta :Počet aktivních ( běžících ) a ve frontě procesů.
Ve druhém příkladu, kdy je systém aktivní, vidíme spuštěnou frontu 8 – to je již maximální horní limit systému s 8 jádry, který by měl běžet. Run queue samozřejmě může ukazovat hodnoty jako 36 nebo dokonce 101 – budou naprosto v pořádku, pokud na prvních 36 budeme mít 36 jader a na druhém 101 budeme mít více než 101 jader.
Sloupec fronty běhu by měl být vždy nižší/stejný jako počet jader nainstalovaných v systému – samozřejmě fronta běhu 100 může být viditelná na systému pouze s 8 jádry – bude to znamenat, že 8 procesů je aktivně obsluhováno CPU a zbývajících 92 je ve frontě a čeká na provedení. Pokud je fronta běhu vyšší než nainstalovaná jádra CPU, mělo by být provedeno šetření z hlediska kontroly výkonu APP/DB a chybějícího ladění nebo může naznačovat, že systém není správně škálován, aby obsluhoval takovou frontu běhu/zatížení.
Stejně jako průměrná zátěžová fronta běhu by měla zůstat pod počtem nainstalovaných jader – neudržení této hodnoty pod maximální prahovou hodnotou způsobí zpomalení/zaseknutí nebo případ vyřazení (pokud je systém povolen HA), protože OS může jednoduše zařadit do fronty sledování srdečního tepu na disku/síti vrstva jako její zaneprázdněná plněním jiných úkolů. Vysoký průměr zatížení a fronta běhu způsobí náhlé selhání/zaseknutí – vyplatí se obě hodnoty aktivně monitorovat pomocí monitorovacích nástrojů třetích stran a upozornit, když fronta běhu / průměr zatížení zabírá více než 70 % skutečných zdrojů CPU.
Druhý důležitý sloupec, který také zaujímá průměr zatížení, je stav „b“ ve vmstat, který vysvětluje procesy blokovaného stavu – to lze snadno interpretovat jako procesy stavu D (čekající na dokončení back-end IO – obvykle Storage Activity). Pokud je průměrná zátěž vysoká a žádné procesy aktivně neběží a vmstat ukazuje abnormální hodnotu stavu „b“, pak je čas zkontrolovat výkon SAN nebo ověřit jakoukoli komponentu operačního systému, jako je ISCSI/NFS/NIC/HBA, která může mít problémy a vést k vážný blokovaný stav pod Linuxem. Například NFS Server může být zaneprázdněn na úrovni CPU a všechny klientské (Linuxové) procesy/úlohy budou zařazeny do fronty ve stavu-d (b), což povede k „zařazení do fronty“, což může následně uvolnit masivní run-queue – jako byly všechny procesy čekání na pozdější ukončení IO na back-endu se mohou znovu přepnout do režimu Running, což povede k masivní frontě běhu, což může způsobit zablokování/panika nebo později vést k případu vystěhování.
Síťová propustnost a provoz TCP/UDP budou také ovlivněny vysokým průměrem zatížení – protože systém bude jednoduše zaneprázdněn obsluhovat jiné úkoly než potvrzovat příchozí/odchozí připojení a upřednostňovat příchozí síťový IO provoz přes NFS/ISCSI atd. V některých případech se může zobrazit TOP až hodnota %CPU být větší než 100, je to naprosto v pořádku, protože příkaz TOP ve výchozím nastavení v Linuxu zobrazuje operace s jedním jádrem, takže ve vícejádrových nastaveních může být hodnota %CPU větší než 100 %. Pokud například PID plně využívá 4 jádra, pak hodnota %CPU bude ukazovat 400
# top top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1438 java 20 0 945m 4220 2528 S 400.5 0.0 56:31.95 java <---
Informace o %CPU:
## %CPU -- CPU Usage The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. In a true SMP environment, if a process is multi-threaded and top is not operating in Threads mode, amounts greater than 100% may be reported. You toggle Threads mode with the 'H' interactive command. ##
Pro rychlý výpis běžících/blokovaných procesů použijte níže uvedený příkaz ps:
# ps r -Af
Chcete-li vypsat vlákna procesů a ověřit, zda některá vlákna vytvořená nadřazeným PID nezpůsobují problém s nárůstem CPU, spusťte:
# ps -e -To pid,ppid,state,pcpu,command
nebo
# ps -elfL
Chcete-li také ověřit, zda procesory OS aktivně obsluhují uživatelský (US) prostor, použijte níže uvedené příklady příkazů:
# sar -P ALL 1 Linux 3.8.13-118.13.3.el6uek.x86_64 (lgeeklab) 01/08/2017 _x86_64_ (8 CPU) 02:40:38 PM CPU %user %nice %system %iowait %steal %idle 02:40:39 PM all 12.62 0.00 0.12 6.88 0.00 80.38 02:40:39 PM 0 0.00 0.00 0.00 54.55 0.00 45.45 02:40:39 PM 1 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 2 0.99 0.00 0.00 0.00 0.00 99.01 02:40:39 PM 3 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 4 100.00 0.00 0.00 0.00 0.00 0.00 02:40:39 PM 5 0.98 0.00 0.98 0.00 0.00 98.04 02:40:39 PM 6 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 7 0.00 0.00 0.00 0.00 0.00 100.00 Average: CPU %user %nice %system %iowait %steal %idle Average: all 12.63 0.00 0.13 6.00 0.00 81.24 Average: 0 0.00 0.00 0.00 45.23 0.00 54.77 Average: 1 0.50 0.00 0.00 3.00 0.00 96.50 Average: 2 0.50 0.00 0.00 0.00 0.00 99.50 Average: 3 0.00 0.00 0.00 0.50 0.00 99.50 Average: 4 100.00 0.00 0.00 0.00 0.00 0.00 Average: 5 0.50 0.00 0.50 0.00 0.00 99.00 Average: 6 0.00 0.00 0.00 0.00 0.00 100.00 Average: 7 0.00 0.00 0.00 0.00 0.00 100.00
# mpstat -P ALL Linux 3.8.13-118.13.3.el6uek.x86_64 (geeklab) 01/08/2017 _x86_64_ (8 CPU) 02:41:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:41:26 PM all 0.79 0.00 0.10 1.18 0.00 0.02 0.00 0.00 97.92 02:41:26 PM 0 0.94 0.00 0.14 2.84 0.00 0.02 0.00 0.00 96.06 02:41:26 PM 1 0.94 0.00 0.14 2.70 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 2 0.93 0.00 0.14 1.13 0.00 0.03 0.00 0.00 97.77 02:41:26 PM 3 0.94 0.00 0.13 2.71 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 4 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.28 02:41:26 PM 5 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 6 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 7 0.64 0.00 0.05 0.01 0.00 0.01 0.00 0.00 99.29
Kromě toho lze níže uvedené přepínače příkazů TOP použít k získání informací o vláknu PID a také to, které jádro naposledy obsluhovalo PID:
Zobrazení vláken v TOP:
# top -H
Chcete-li zobrazit, které jádro obsluhovalo PID naposledy:
# top
Poté stiskněte 'F “ a stiskněte „J “ a stiskněte klávesu Enter pro získání výstupu níže, kde je „P ' řádek bude naposledy použitý CPU.
Tasks: 1045 total, 2 running, 1043 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 93.6%id, 5.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16159656k total, 15349888k used, 809768k free, 597960k buffers Swap: 8232956k total, 218784k used, 8014172k free, 9840192k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 10428 root 20 0 15228 2228 1724 S 0.7 0.0 0:26.86 2 top 10838 oracle 20 0 4921m 585m 5708 S 0.7 3.7 137:11.13 3 mysqld 15360 root 20 0 15888 2792 1724 R 0.7 0.0 0:00.55 6 top 528 root 20 0 0 0 0 S 0.3 0.0 76:39.23 0 jbd2/dm-0-8 9003 root 20 0 0 0 0 S 0.3 0.0 8:49.33 2 jbd2/dm-3-8 10815 oracle 20 0 4921m 585m 5708 S 0.3 3.7 13:35.18 1 mysqld 14902 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 19:54.77 3 java 15021 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 20:09.19 1 java 15094 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 6:54.88 3 java 32045 enduser 20 0 15228 2220 1724 S 0.3 0.0 9:32.73 5 top 32278 root 20 0 15228 2212 1724 S 0.3 0.0 9:32.96 1 top
Nejčastější dotazy
Měl by systém běžet s horním limitem jako 8 běžících procesů se stejnou hodnotou zatížení na 8jádrovém systému?
Odpověď – Ne
Systém by měl být správně škálován a neměl by překročit 70 % jeho možností - takže existuje určitý prostor pro provádění jakýchkoli nových úloh - to je zvláště důležité pro servery s povoleným HA a pro systémy, kde jsou jakékoli high-endové IO/síťové komponenty, které mohou být náhodně zařazeny do fronty aktivním OS. Tuto hloubkovou kontrolu by měl provést tým APP/DB, aby ověřil, co přesně v OS aktivně běží.
Způsobují pouze úlohy APP/DB vysoký běh fronty/průměr zatížení
Odpověď – Ne
Některé úlohy operačního systému mohou způsobit vysokou frontu běhu nebo průměrné zatížení - ale to jsou opravdu vzácné případy. V tomto případě bude příkaz top užitečný pro sledování hodnot US /SY / NI / ID / WA / HI / SI / ST a zaměření na sekci SY ( System ), která říká, kolik času procesoru stráví na úrovni jádra. Ujistěte se, že je vždy nižší než skutečné využití v USA (Uživatel) a SY nevyužívá například 20-30 % CPU (závisí na nastavení CPU a skutečném případě).
Vysoký %SY může být například viditelný během High IO/Network operací nebo během případů nedostatku paměti - příklad procesu je:kjorunald. Vysoká %SY může být viditelná také při velkém zatížení systému – například fronta s vysokým spouštěním nebo blokovaná fronta, která je způsobena úlohami APP/DB – většinou se pak pozoruje, že %SY bude kolem 20-30 %, kde bude %US být mnohem vyšší.
Vyšší %SY neznamená vždy problém s jádrem nebo operačním systémem – například může existovat kód aplikace/databáze, který způsobuje mnoho systémových volání kolem konkrétní funkce jádra – k odladění tohoto dalšího strace nebo perf by se mělo použít ověřit konkrétní interakci PID.
Znamená to, že jedno jádro může v daném okamžiku obsluhovat pouze jeden procesní úkol?
Odpověď – Ano/Ne
CPU jsou navrženy pro multitasking – i v případě jednojádrového systému mohou uživatelé stále provádět více úloh a spouštět více aplikací – v jednojádrovém nastavení se používá „časové dělení“, které umožňuje provádění úloh po určitou dobu, zatímco ostatní úlohy budou čekat na být proveden (může se to stát několikrát za sekundu).
Moderní systémy budou využívat vícejádrové/vícevláknové funkce, aby byl dopad přepínání méně viditelný – uživatelé Enterprise Systems proto mají vícejádrové nastavení, kde aplikace mohou vytvářet menší vlákna, která dosáhnou skutečných multitaskových operací (každé jádro může sloužit jinému úkolu), což vede k mnohem více nižší průměrná zátěž systému a nižší fronta úloh - Například dvoujádrový systém může rozdělit aplikace/vlákna/úlohy na dvě samostatná jádra, což umožňuje jádru přepínat pouze polovinu úloh ve srovnání s jednojádrovým systémem, což má mnohem menší dopad na výkon systému.