Dobré nástroje pro odstraňování problémů se systémem jsou vším. Skvělé nástroje se však hledají obtížněji. Naštěstí Linux přichází s množstvím vynikajících programů a utilit, které vám umožňují profilovat, analyzovat a řešit problémy s chováním systému, od úzkých míst aplikací až po špatné konfigurace a dokonce i chyby. Vše začíná nástrojem, který dokáže získat potřebné metriky a poskytnout vám data, která potřebujete.
Health-check je úhledný program, který dokáže monitorovat a profilovat procesy, takže můžete identifikovat a vyřešit nadměrné využití zdrojů – nebo související problémy. Kde vyniká ve srovnání se zbytkem davu – jeho cílem je nabídnout mnoho užitečných aspektů systémových dat současně, takže můžete snadněji prohledávat komponenty, odstraňovat problémy s výkonem a opravovat konfigurační chyby ve vašem prostředí. Místo abyste museli spouštět pět nástrojů současně nebo provádět pět běhů, abyste získali všechny potřebné informace, stačí použít kontrolu stavu a Bob je váš vzdálený příbuzný. Dobrý. Dobře, připraven? Pokračujte.
Zdravotní kontrola v akci
Než spustíme nástroj ve vzteku, několik malých poznámek. Za prvé, ke spuštění tohoto nástroje potřebujete oprávnění sudo, ačkoli skutečnou aplikaci můžete spouštět v kontextu ostatních uživatelů v systému (s parametrem -u). Za druhé, potřebujete trochu porozumět tomu, jak Linux funguje, abyste mohli využít výsledky – mám na toto téma spoustu článků, na které odkazujeme níže.
V podstatě, jak jsem před chvílí nastínil, Health-check spojuje funkce z různých programů pod jeden deštník. Pěkně kombinuje prvky, které byste získali, pokud byste spustili netstat, lsof, vmstat, iostat a zkoumali různé struktury pod /proc a /sys. Je to něco jako dstat, který kombinuje sílu vmstat, iostat a ifstat. Můžete začít jednoduchým spuštěním (příznak -b):
sudo ./health-check -u "user" -b "binary"
I v tomto „krátkém“ režimu bude hodně výstupů, něco jako:
Využití CPU (v přepočtu na 1 CPU):
Uživatel:34,24 %, Systém:13,30 %, Celkem:47,54 % (vysoká zátěž)
Nejprve získáte základní údaje o CPU, normalizované na jádro (100 % =1 celé jádro). Health-check má interní prahové hodnoty, podle kterých bude indikovat, zda se jedná o nízkou, střední nebo vysokou zátěž. To je jen proto, abyste měli představu o tom, co byste měli očekávat. Specifika budou záviset na typu aplikace a pracovní zátěži, kterou profilujete. Budou zde rozdíly mezi GUI a nástroji příkazového řádku, softwarem, který čte z databáze do databáze, která nečte, softwarem s velkým počtem sdílených knihoven, používáním hardwaru atd.
Chyby stránky:
Proces PID Minor/s Hlavní/s Celkem/s
1043 google-chrome 16156,46 0,25 16156,71
V minulosti jsme dlouze mluvili o chybách stránek (odkazy v sekci pro další čtení níže). Pokud nevíte, co má vaše aplikace dělat, čísla vám sama o sobě mnoho neřeknou. Mohou však být velmi užitečné pro srovnávací studie, jako jsou dva různé programy stejného typu nebo dvě různé verze stejného programu nebo stejný program běžící na dvou různých platformách.
Přepnutí kontextu:
13687,53 přepnutí kontextu/s (velmi vysoká)
Hodnota kontextového přepínače udává, jak často se jádro vzdává běhové fronty a přepíná mezi úlohami. U interaktivních procesů (jako je prohlížeč), které mají uživatelsky interaktivní komponentu, skutečně chcete co nejvíce kontextových přepínačů (úlohy běží co nejméně), protože nechcete, aby tyto úlohy zatěžovaly procesor. Ve skutečnosti je dlouhý výpočet znakem dávkových úloh. Zde může nedostatek přepínání kontextu znamenat problém s interaktivní (GUI) aplikací, jako je prohlížeč.
Souborové I/O operace:
I/O operace za sekundu:312,80 otevření, 283,49 uzavření, 768,71 čtení,
410,83 zápis
Hodnoty I/O jsou užitečné, pokud máte základní linii, a také závisí na základním zásobníku I/O, včetně hardwaru, sběrnice, ovladače, výběru souborového systému a jakýchkoli dalších diskových operací spuštěných ve stejnou dobu.
Analýza systémových hovorů polling:
google-chrome (1043), poll:
1555 okamžitých hovorů s vypršením časového limitu s nulovým časovým limitem (neblokující nahlédnutí)
1 opakovaný časový limit dotazovaných hovorů s nenulovou hodnotou časové limity
(lehké dotazování)
1125 opakovaných okamžitých dotazovaných hovorů s vypršením časového limitu s nulovými časovými limity
(silné dotazování)
Tato sekce je dalším indikátorem možné uživatelské interaktivity profilované binárky. Systémová volání dotazování jsou systémová volání, která čekají, až budou popisy souborů připraveny k provádění I/O operací. Obvykle to bude indikovat síťová připojení. Prozkoumáme to podrobněji, až provedeme úplný běh.
Paměť:
Změna paměti (K/sekunda):
PID Typ procesu Velikost RSS PSS
1043 google-chrome Zásobník 32,51 27,59 27,59 (rostoucí
středně rychle)
1043 google-chrome Heap 67550,94 9092,51 9112,70 (roste velmi
rychle)
1043 google-chrome Mapped 102764,33 27296,24 18781,80 (roste velmi rychle)
Pro většinu lidí a většinu typů aplikací nebudou operace s pamětí tak zajímavé. Paměťově náročné úlohy nejsou u stolního softwaru tak obvyklé. Mohou být docela důležité pro databáze a složité výpočty, něco, co byste normálně dělali na systému třídy serverů. Ale tuto sadu čísel lze použít ke zkoumání rozdílů mezi platformami, jádry a verzemi softwaru.
Otevřená síťová připojení:
Proces PID Proto Odeslat Přijímací adresa
1043 google-chrome UNIX 531,52 K 35,16 K /run/user/1000/bus
1043 google-chrome UNIX 0,00 B 88,56 K /run /systemd/journal/...
1043 google-chrome 64,51 K 0,00 B zásuvka:[2737924]
1043 google-chrome 30,55 K 0,00 B zásuvka:[2746558]
1043 google-chrome 3,98 K 0,00 B zásuvka:[2742865]
...
Sada čísel síťových připojení vám dává výsledky, které jsou podobné tomu, co dělají netstat a lsof, ale také získáte hodnoty pro odesílání a přijímání, což může být docela užitečné. Pokud víte, co má program dělat po síti, můžete profilovat jeho provádění a hledat možné nesprávné konfigurace v síťovém zásobníku.
Delší (podrobný) běh
Můžete se také rozhodnout pro více statistik (například s parametry -c -f, no -b). Získáte rozšířené výsledky pro každou z sekcí, o kterých jsme hovořili dříve, a to vám může poskytnout další pohled na to, jak se váš software chová. Pokud sledujete dětské procesy a větvení, můžete vidět sekvenci provádění. Statistiky CPU budou uvedeny na základě využití, s nejvyššími pachateli nahoře.
Využití CPU (v přepočtu na 1 CPU):
Proces PID USR% SYS% TOTAL % Trvání
1715 vlc 47,04 8,17 55,21 14,71 (vysoké zatížení)
1720 vlc 46,91 7,93 14. zatížení )
1723 vlc 46,77 7,96 54,74 14,35 (vysoké zatížení)
...
1721 vlc 1,69 1,08 2,77 1,21 (nízké zatížení)
1722 y 07 010,0 0.0. )
1726 vlc 0,07 0,00 0,07 0,02 (velmi nízká zátěž)
1742 vlc 0,00 0,00 0,00 0,07 (neběh naprázdno)
1732 vlc 0,00 0,0 0.0 0,00 0,06 (nečinnost)
1719 vlc 0,00 0,00 0,00 0,06 (nečinnost)
Celkem 971,80 161,72 1133,52 (plně nabitý CPU)
Ve výše uvedeném příkladu jsme při spuštění VLC (s přehráváním HD klipu asi 14 sekund) využili 1 133 % času CPU, což se promítá do 11,33 jader CPU. To zní hodně, ale protože systém má osm jader (vlákna), ve skutečnosti to znamená, že pro video bylo skutečně použito pouze 1,5 jádra. Bylo by také zajímavé skutečně vědět, která jádra byla použita.
Kontextové přepínače:
Proces PID Dobrovolný Nedobrovolný Celkem
Ctxt Sw/Sec Ctxt Sw/Sec Ctxt Sw/s
1744 vlc 2500,09 1,15 2501,24 (vysoký)
1723 vl85,29 1723 vl8,29 vysoká)
1740 vlc 1224,03 3,31 1227,33 (vysoká)
1717 vlc 947,43 0,40 947,84 (docela vysoká)
1731 vlc 736,37> 37,07
Pokud jde o chyby stránek, není nic nového. S přepínači kontextu také získáme seznam dobrovolných a nedobrovolných CS. Druhá skupina může být známkou toho, že úkoly překračují svůj přidělený úsek, což by pak mělo za následek, že při příštím spuštění budou mít nižší dynamickou prioritu (což není dobré pro interaktivní procesy).
Soubor I/O operace:
PID Process Count Op Název souboru
1715 vlc 176 R /home/roger/developers.webm
1715 vlc 48 C /etc/ld.so.cache
1715 vlc 48 O /etc/ld.so.cache
1715 vlc 34 R /usr/share/X11/locale/locale.alias
File I/O nyní také zobrazuje počet operací na proces, typ operace a také název souboru. Nemusí to být skutečný soubor na disku, může to být také sběrnice. Dostupné operace jsou vytištěny ve spodní části této části. Jak přesně jsou operace čtení a zápisu prováděny, závisí na mnoha faktorech.
...
1715 vlc 1 C /lib/x86_64-linux-gnu/libnss_systemd.so.2
1715 vlc 1 OR /usr/bin/vlc
Celkem 4352
Op :O=Otevřít, R=Číst, W=Zápis, C=Zavřít
Získáte také frekvenci těchto I/O operací:
Soubor I/O operace za sekundu:
Proces PID Otevřít Zavřít Číst Zápis
1715 vlc 100,57 96,72 89,77 1,75
1719 vlc 3,24 4,99 3,04 0,00
...
Další část je o systémových voláních a je velmi podrobná. Výstup je podobný strace. Budete mít ID procesu, název procesu, systémové volání, počet, rychlost, celkový čas (v nás) a procento, které každé systémové volání zabralo z celkového času provedení. Tato čísla nemůžete interpretovat, pokud nevíte, co má aplikace dělat, nebo pokud je nemůžete porovnat se základní linií.
2 Trasovaná systémová volání:
PID Process Počet Syscall Počet Rychlost/s Celková doba hovoru uSecs %
1715 vlc stat 429 28,9555 3004 0,0011
1715 vlc mmap 240 15,191891 protect <00 16,191971 13,7015 4739 0,0017
...
Tyto informace jsou užitečnější, když se podíváte na systémová volání dotazování. Pro stručnost jsem výstup níže mírně upravil. Všechna poslední čtyři pole označují časové limity, např.:Zero Timeout, Minimální časový limit atd. V podstatě vám dávají indikátor toho, jak dlouho trvalo, než se tato systémová volání dokončila. Pole Nekonečný počet odkazuje na systémová volání, která měla nekonečné čekání (po dobu běhu aplikace). Informace jsou také zobrazeny jako histogram za proces, od nuly do nekonečna, logaritmicky rozdělený do segmentů až do 10us, 10-99 us, 100-99 us atd.
Nejvyšší polling systémová volání:
PID Process Syscall Rate/Sec Inf Zero Min Max Avg
1715 vlc poll 3,2398 45 1 0,0 s 25,0 s 1,0 s
1715 vlc rt_sigtimed 0,0 s 0,1 0,0 s
1717 vlc poll 124,7312 5 1 0,0 s 30,0 s 958,4 ms
...
Podrobnější výstupní protokol bude také obsahovat data synchronizace souborového systému.
Synchronizace souborového systému:
PID fdatasync fsync synchronizace celkem syncfs celkem (Rate)
1723 0 2 0 0 2 0,13
Synchronizované soubory:
PID syscall # název souboru synchronizace
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.lock
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.XM1715
A konečně, podrobný výstup bude mít také informace o paměti a připojení k síti, ale hlavním rozdílem budou výsledky zobrazené na proces. Jak jsme již uvedli dříve, první nebude obvykle užitečný pro většinu pracovních zátěží na počítači (pokud nejste vývojářem programu), zatímco druhý může být užitečný při hledání problémů v síťovém zásobníku.
Health-check vytváří poměrně velkou sadu výsledků, ale poskytuje mnoho informací o tom, jak se vaše aplikace chovají. Jeho použití můžete zkombinovat s jiným softwarem, abyste získali úplnou analýzu svého softwaru a odstranili případné problémy s výkonem. Health-check může také profilovat spuštěné úlohy (příznak -p), díky čemuž je docela užitečný jako doplněk k vaší sadě nástrojů pro řešení problémů.
Ruční nastavení
Pokud nejste spokojeni s verzí dostupnou v repozitářích, můžete ji zkompilovat ručně. Dalším důvodem, proč to udělat, je obejít všechny možné problémy, které mohou mít starší verze, jako je například chyba timer_stats, kdy se nástroje snaží získat přístup k /proc/timer_stats, ale tato struktura již není v nejnovějších jádrech odhalena:
Nelze otevřít /proc/timer_stats.
Opravdu, pokud zaškrtnete, dostanete:
cat /proc/timer_stats
cat:/proc/timer_stats:Žádný takový soubor nebo adresář
Pro kompilaci spusťte:
git klon https://kernel.ubuntu.com/git/cking/health-check.git/
cd health-check
make
Může se zobrazit následující chyba:
json.h:25:10:fatální chyba:json-c/json.h:Žádný takový soubor nebo adresář
#include
To znamená, že vám chybí vývojový balíček pro JSON, který nástroj potřebuje k úspěšné kompilaci. Skutečný název balíčku se bude lišit od jedné distribuce k druhé, ale v mém testu na Kubuntu vyřešilo chybu kompilace následující:
sudo apt-get install libjson-c-dev
Další čtení
Pokud máte zájem o další nástroje pro řešení problémů se systémem, pak:
Linux super-duper nástroje pro správu:strace
Linux super-duper nástroje pro správu:lsof
Linux super-duper nástroje pro správu:gdb
Pomalý systém? Perf k záchraně!
Super návod na ladění systému LinuxSkvělé hacky Linuxu – první až čtvrtá část – spojující pouze poslední.
V neposlední řadě moje kniha o řešení problémů!
Závěr
Kontrola stavu je velmi užitečný a praktický nástroj. Nenahrazuje strace, netstat nebo perf, ale může vám jistě pomoci získat velmi přesný vícerozměrný snímek čehokoli, co profilujete. Toto je velmi dobrý první krok, který vás může nasměrovat správným směrem. Poté můžete vybrat nástroj, který konkrétně zkoumá relevantní aspekt běhu softwaru (možná Wireshark pro síť nebo Valgrind pro paměť). Svým způsobem to dělá z kontroly zdraví Jack o' All Trades.
Potřebujete trochu porozumět tomu, jak systémy Linux fungují – a aplikaci, kterou používáte. Ale i když tyto znalosti nemáte, Health-check může být použit pro srovnávací studie a odstraňování problémů s výkonem. Pokud víte, že něco nefunguje tak dobře, jak by mělo, můžete to vysledovat jednou na dobrém systému, jednou na špatném (postiženém) systému a poté oba porovnat. Mnoho typů dat, které poskytuje kontrola stavu, výrazně pomůže při řešení problému. A tím se dostáváme na konec tohoto návodu. S trochou štěstí jste se naučili něco nového a byla to také příjemná jízda. Opatruj se.