strace a perf pro řešení problémů v systému Linux

Když je linuxový server pomalý, padá nebo přetěžuje procesor a aplikační logy nevysvětlují proč, dva nástroje pokryjí většinu mezer. strace strace vám řekne, o co proces žádá jádro. perf vám řekne, kde CPU tráví svůj čas. Společně odpovídají na otázky „proč se to zaseklo“ a „co to dělá“, které nic jiného nezvládne tak levně.

Tento příspěvek se zabývá tím, kdy sáhnout po kterém nástroji, jak je nainstalovat, jaké příkazy budete skutečně spouštět a jak udržet režii na živém serveru pod kontrolou.

Kdy použít strace a kdy perf

Rozdíl je jednoduchý. Použijte perf , když je CPU zaneprázdněno a potřebujete zjistit, která funkce je za to zodpovědná. Použijte strace , když proces zamrzá, havaruje, vrací podivné chyby nebo se chová způsobem, který logy nevysvětlují.

perf vzorkuje hardwarové čítače jádra s konfigurovatelnou frekvencí, takže režie je obvykle pod 1 % a je bezpečné jej spouštět v produkčním prostředí. strace zachytává každé systémové volání prostřednictvím ptrace, což může zpomalit cílový proces 10x až 100x. Používejte jej na živých systémech jen zřídka a vždy s filtry.

Instalace strace a perf

Oba nástroje jsou v standardních repozitářích. strace využívá ptrace syscall, který je již řadu let součástí každého moderního jádra. perf využívá rozhraní perf_events rozhraní a vyžaduje balíček, který odpovídá vašemu spuštěnému jádru.

Na Ubuntu nebo Debianu:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

Na RHEL, AlmaLinux nebo Fedora:

sudo dnf install strace perf

Na $(uname -r) bit je důležitý. Binární soubor perf sestavený proti jiné verzi jádra produkuje matoucí výstup a může tiše vynechávat události. Ověřte pomocí perf --version a strace -V po instalaci.

Aby perf zobrazoval názvy funkcí namísto hexadecimálních adres, potřebujete ladicí symboly. Nainstalujte příslušný -dbg nebo -debuginfo (například libc6-dbg v Debianu) a zkompilujte si vlastní binární soubory pomocí -g v GCC.

Uvnitř kontejnerů strace potřebuje --cap-add=SYS_PTRACE a perf potřebuje --cap-add=SYS_ADMIN při spouštění s Dockerem. Bez těchto omezení selhávají nástroje způsobem, který vypadá jako chyby.

Sledování systémových volání pomocí strace

Spuštění strace command sleduje proces od jeho spuštění. Chcete-li se připojit k běžícímu procesu, použijte strace -p PID. U všeho, co je multithreadové nebo se rozvětvuje, přidejte -f , abyste sledovali potomky, jinak vám unikne většina aktivity.

Výstupní řádky končí návratovou hodnotou. -1 ENOENT znamená, že soubor, o který proces požádal, neexistuje. -1 EACCES znamená oprávnění. Tyto dvě chyby samy o sobě představují překvapivě velký podíl chyb v produkčním prostředí.

Nejužitečnější příznak je -e trace=GROUP, která omezuje výstup na pojmenovanou kategorii systémových volání a udržuje množství výstupu na přijatelné úrovni.

Na vytíženém serveru začněte s strace -c -p PID na deset nebo dvacet sekund. Příznak -c příkaz vypíše souhrn počtu systémových volání, celkového času a chyb při odpojení. To vám řekne, kterou kategorii stojí za to prozkoumat blíže, aniž by se terminál zaplavil daty. Poté se znovu připojte s úzkým filtrem.

Další příznaky, které stojí za to znát: -T zaznamenává čas strávený v každém volání, -Z zobrazí pouze neúspěšná volání a -o file zapisuje do logu místo do terminálu, což je u hlučného procesu mnohem rychlejší.

Profilování CPU pomocí perf

perf má čtyři příkazy, které budete používat nejčastěji.

Začněte s perf stat -p PID pro rychlý přehled. Čísla, na která je třeba dávat pozor:

• IPC (instrukce na cyklus) pod 1,0: CPU se zdržuje, obvykle při přístupu k paměti.
• Vysoký počet LLC-load-misses: pracovní sada se nevejde do cache, takže CPU čeká na RAM.
• Vysoký počet přepnutí kontextu: klasický případ pro úlohy vázané na I/O, kde vlákna neustále blokují disk nebo síť.

Pokud se něco nezdá, pokračujte pomocí perf record -F 99 -g -p PID -- sleep 30. -F 99 vzorkuje na 99 Hz, což stačí k nalezení nejvyužívanějších funkcí a vyhýbá se synchronizaci s časovačem jádra na kulatých číslech, jako je 100 Hz. Příznak -g zachytí grafy volání, takže perf report vám může ukázat, které cesty do funkce jsou za to zodpovědné.

Ve perf reportsloupci Overhead je uveden podíl na celkovém počtu vzorků. Vysoká režie v _int_malloc nebo memcpy znamená velkou alokaci. Vysoká režie v jedné z vašich vlastních funkcí je tím problémovým místem, které jste hledali.

Pokud vidíte hexadecimální adresy namísto názvů funkcí, je binární soubor zbaven symbolů nebo chybí ladicí symboly. Nainstalujte odpovídající -dbg balíček nebo přeložte binární soubor s -g.

Praktický pracovní postup na živém serveru

V případě skutečné události na vytíženém serveru vypadá postup takto:

1. Nejprve potvrďte příznak pomocí jednoduchých nástrojů: top, vmstat, iostat. Pokud používáte virtuální stroj, zkontrolujte sloupec st sloupec (steal). Hodnota nad 5 % znamená, že úzkým hrdlem je hypervisor, nikoli váš kód.
2. Pokud je využití CPU vysoké, spusťte perf top na několik sekund a poté perf record -F 99 -g -p PID -- sleep 30 pro problematický proces. 30sekundový záznam při 99 Hz vyprodukuje přibližně 1,7 MB dat.
3. Pokud je proces zaseknutý, pomalý nebo vrací chyby, spusťte strace -c -p PID po dobu deseti sekund a přečtěte si souhrn. Pokud dominuje jedna kategorie systémových volání, zúžte výběr pomocí strace -e trace=GROUP -T -p PID.
4. Jakmile najdete podezřelé systémové volání nebo funkci, odpojte se. Nenechávejte žádný z nástrojů běžet na produkčním prostředí déle, než je nutné.

Dvě upozornění. strace Výstup může obsahovat proměnné prostředí, cesty k souborům a bajty načtené ze soketů, proto před sdílením protokolů mimo váš tým proveďte jejich čištění. A pokud to budete dělat pravidelně, podívejte se jako další krok na bpftrace a širší sadu nástrojů eBPF jako další krok: stejný druh přehledu, režie pod 1 %, od začátku vytvořené pro produkční prostředí.

Pokud provozujete pracovní úlohy, u nichž je důležitý hluboký diagnostický přístup a sdílená infrastruktura nepřichází v úvahu, podívejte se na naše dedikované servery.