Pokud jste dělali práci správce systému dostatečně dlouho, viděli jste obávané incidenty „Server je pomalý“. Dlouhou dobu by mi z těchto typů incidentů hrozila díra v žaludku. Jak sakra řešíte něco tak subjektivního? "Zpomalení" běžného uživatele může být způsobeno jinými procesy (naplánovanými nebo ne), které běží a spotřebovávají více zdrojů než obvykle, nebo může být se serverem něco v nepořádku.
Když jsem poprvé začal pracovat jako systémový správce, okamžitě bych odpověděl:"Potřebuji o tom více informací." Uživatel obvykle není schopen poskytnout žádné další informace, protože neví, co běží v zákulisí nebo jak vysvětlit, co vidí, jinak než „je to jen pomalé“. V dnešní době, než uživateli vůbec odpovím, zkontroluji pár věcí.
Počáteční přihlášení
Je toho hodně, co můžete zjistit po přihlášení k hostiteli. Můžete se vůbec přihlásit? Je přihlášení pomalé nebo visí? ssh příkaz má tři úrovně ladění, z nichž každá vám poskytne nepřeberné množství informací ještě předtím, než budete v systému. Chcete-li povolit ladění, stačí přidat další v na -v volba. Například ladění třetí úrovně, které používám výhradně já, by bylo:
[~]$ ssh -vvv hostname.domain.com
Velká 3 (také znám jako CPU, RAM a disk I/O)
Nyní se podívejme na tři největší příčiny zpomalení serveru:CPU, RAM a diskové I/O. Využití CPU může způsobit celkovou pomalost hostitele a potíže s včasným dokončením úkolů. Některé nástroje, které používám při pohledu na CPU, jsou top asar .
Kontrola využití procesoru nahoře
top nástroj vám poskytuje pohled v reálném čase na to, co se děje na serveru. Ve výchozím nastavení, když je top spustí, zobrazí aktivitu pro všechny CPU:
Toto zobrazení lze změnit stisknutím číselné klávesy 1, která přidá další podrobnosti týkající se hodnot využití pro každý CPU:
Některé věci, které byste v tomto zobrazení měli hledat, je průměrná zátěž (zobrazená na pravé straně horního řádku) a hodnota následujících pro každý CPU:
us:Toto procento představuje množství CPU spotřebované uživatelskými procesy.sy:Toto procento představuje množství CPU spotřebované systémovými procesy.id:Toto procento představuje nečinnost jednotlivých CPU.
Každá z těchto tří hodnot vám může poskytnout poměrně dobrou představu v reálném čase o tom, zda jsou CPU vázány uživatelskými nebo systémovými procesy.
Skutečné vysvětlení průměrné zátěže by vyžadovalo samostatný článek. Pro účely tohoto článku budu mluvit obecně. Tři průměrné hodnoty zatížení zleva doprava představují jednominutové, pětiminutové a 15minutové průměry. Znovu říkám velmi obecně, pokud vidíte, že průměr za jednu minutu překračuje počet fyzických CPU, které máte, pak je systém s největší pravděpodobností vázán na CPU.
Poznámka: Další informace o průměrné zátěži a o tom, proč si někteří lidé myslí, že je to hloupé číslo, najdete v hloubkovém výzkumu Brendana Gregga.
Kontrola všech „velkých 3“ pomocí sar
U historických údajů o výkonu CPU se spoléhám na sar příkaz, který poskytuje sysstat balík. Na většině serverových verzí Linuxu sysstat je standardně nainstalován, ale pokud není, můžete jej přidat pomocí správce balíčků vašeho distribuce. sar obslužný program shromažďuje systémová data každých 10 minut prostřednictvím úlohy cron umístěné v /etc/cron.d/sysstat (CentOS 7.6). Zde je návod, jak zkontrolovat všechny „velké 3“ pomocí sar .
Poznámka: Pokud jste právě nainstalovali sar Chcete-li pokračovat podle tohoto článku, dejte příkazu nejprve nějaký čas na zaznamenání dat.
Příkaz sar -u poskytuje informace o všech CPU v systému, počínaje půlnocí:
Stejně jako u top , hlavní věci ke kontrole jsou %user , %system , %iowait a %idle . Tyto informace vám mohou říci, jak daleko do minulosti měl server problémy.
Celkově sar příkaz může poskytnout mnoho informací. Protože tento článek vysvětluje pouze rychlou kontrolu toho, co se děje na serveru, podívejte se na man sar abychom tyto informace rozebrali ještě dále.
Ke kontrole výkonu RAM používám sar -r , které vám poskytují denní využití paměti:
Hlavní věc, kterou je třeba hledat při využití RAM, je %memused a %commit . Krátké slovo o %commit pole:Toto pole může ukazovat více než 100 %, protože linuxové jádro běžně přetěžuje RAM. Pokud %commit je trvale nad 100 %, tento výsledek by mohl být indikátorem toho, že systém potřebuje více paměti RAM.
Pro výkon disku I/O používám sar -d , který vám poskytuje výstup I/O disku pouze pomocí názvu zařízení. Chcete-li získat název zařízení, použijte sar -dP :
Pro tento výstup se podívejte na %util a %await vám poskytne dobrý celkový obraz o diskových I/O v systému. %util pole je docela samovysvětlující:Jde o využití tohoto zařízení. await pole obsahuje množství času, který I/O stráví v plánovači. Čekání se měří v milisekundách a v mém prostředí jsem viděl, že cokoli delší než 50 ms začíná způsobovat problémy. Tento práh se může ve vašem prostředí lišit.
Pokud některý z těchto příkazů ukazuje problém, můžete se vrátit a zjistit, kdy začaly problémy se serverem, pomocí sar {-u, -r, -d, -dP} -f /var/log/sa/sa<XX> (kde XX je den v měsíci, který chcete vyhledat).
V tuto chvíli mám obvykle dobrou představu o tom, co se aktuálně děje na serveru a co se děje za posledních zhruba 48 hodin. Odpovím uživateli informovanějšími odpověďmi. Například:„Za posledních 24 hodin nevidím žádné známky zpomalení hostitele. Zkuste prosím použít nový profil putty pro ssh a dejte mi vědět, pokud budete mít i nadále problémy."
Další příklad:„Nevidím nic, co by v současné době na tomto hostiteli způsobovalo problémy, ale zaznamenal jsem vyšší zatížení CPU $time . Tehdy jsi viděl problémy? Pokud ano, zkuste to prosím nyní a dejte mi vědět, pokud problémy přetrvávají."
Dostanete nápad. Mít informace poskytnuté pohledem na počáteční přihlášení a následným spuštěním několika sar Příkazy, jejichž spuštění mi obvykle zabere méně než 10 minut, dělá hodně pro to, abych odvrátil další otázky a rychleji dosáhl řešení.