strace és perf a Linux hibaelhárításához

Ha egy Linux-szerver lassú, összeomlik vagy túlterheli a CPU-t, és az alkalmazásnaplók nem adnak magyarázatot erre, két eszköz segít a probléma nagy részének megoldásában. strace megmutatja, mit kér egy folyamat a kerneltől. perf megmutatja, mire fordítja az idejét a CPU. Együttesen megválaszolják a „miért akadt el” és „mit csinál” kérdéseket, amit semmi más nem tud ilyen olcsón megoldani.

Ez a bejegyzés bemutatja, mikor érdemes az egyes eszközöket használni, hogyan kell telepíteni őket, milyen parancsokat kell futtatni, és hogyan lehet a terhelést kezelhető szinten tartani egy élő szerveren.

Mikor használjuk a strace-t és mikor a perf-et?

A különbség egyszerű. Használja a perf -t, ha a CPU leterhelt, és tudni szeretné, melyik funkció felelős ezért. Használja a strace -t, ha egy folyamat lefagy, összeomlik, furcsa hibákat jelez, vagy olyan módon viselkedik, amit a naplófájlok nem magyaráznak.

perf a kernel hardveres számlálóit konfigurálható gyakorisággal mintavételezi, így a terhelés általában 1% alatt marad, és biztonságosan futtatható termelési környezetben. strace minden rendszerhívást elfog ptrace, ami 10-100-szorosára lassíthatja a célfolyamatot. Élő rendszereken csak ritkán használja, és mindig szűrőkkel együtt.

A strace és a perf telepítése

Mindkét eszköz megtalálható a standard tárolókban. A strace a ptrace syscall-ra támaszkodik, amely évek óta minden modern kernel része. A perf a perf_events interfészt, és szüksége van egy olyan csomagra, amely megfelel a futó kernelnak.

Ubuntu vagy Debian esetén:

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

RHEL, AlmaLinux vagy Fedora rendszeren:

sudo dnf install strace perf

A $(uname -r) bit fontos. A másik kernelverzióra épített perf bináris fájl zavaros kimenetet eredményez, és előfordulhat, hogy eseményeket hagy ki. Ellenőrizze a perf --version és strace -V parancsokkal.

Ahhoz, hogy a perf hexadecimális címek helyett függvényneveket jelenítse meg, hibakeresési szimbólumokra van szükség. Telepítse a megfelelő -dbg vagy -debuginfo csomagot (például libc6-dbg Debian esetén), és fordítsa le saját bináris fájljait -g a GCC-ben.

Konténerekben strace szükség --cap-add=SYS_PTRACE és perf szükséges --cap-add=SYS_ADMIN Dockerrel történő indításkor. Ezen korlátozások nélkül az eszközök olyan hibákat produkálnak, amelyek bugoknak tűnnek.

Rendszerhívások nyomon követése a strace segítségével

A strace command parancs futtatása nyomon követi a folyamatot az indítástól kezdve. Futó folyamathoz való csatlakozáshoz használja a strace -p PIDparancsot. Bármilyen többszálas vagy elágazó folyamat esetén adja hozzá a -f parancsot a gyermekfolyamatok követéséhez, különben a tevékenység nagy részét kihagyja.

A kimeneti sorok visszatérési értékkel végződnek. -1 ENOENT azt jelenti, hogy a folyamat által kért fájl nincs meg. -1 EACCES a jogosultságokat jelenti. Ez a két hiba önmagában is meglepően nagy arányban részesedik a termelési hibákból.

A leghasznosabb flag a -e trace=GROUP, amely a kimenetet egy megnevezett rendszerhívás-kategóriára korlátozza, és így a zajt kezelhető szinten tartja.

Egy forgalmas szerveren kezdje strace -c -p PID parancsot tíz-húsz másodpercig. A -c flag kinyomtatja a rendszerhívások számának, a teljes időnek és a leválasztáskor fellépő hibáknak az összefoglalását. Ez megmutatja, melyik kategóriát érdemes közelebbről megvizsgálni anélkül, hogy elárasztaná a terminált. Ezután csatlakozzon újra egy szűk szűrővel.

Egyéb érdemes ismerni: -T naplózza az egyes hívásokban eltöltött időt, -Z csak a sikertelen hívásokat jeleníti meg, és -o file naplóba ír a terminál helyett, ami zajos folyamatok esetén sokkal gyorsabb.

A CPU profilozása a perf segítségével

A perf négy parancsot tartalmaz, amelyeket a legtöbb esetben használni fog.

Kezdje perf stat -p PID a gyors áttekintéshez. A figyelemre méltó számok:

• 1,0 alatti IPC (ciklusonkénti utasítások száma): a CPU leáll, általában memóriához való hozzáféréskor.
• Magas LLC-load-misses: a munkakészlet nem fér el a gyorsítótárban, ezért a CPU a RAM-ra vár.
• Magas kontextusváltás-szám: jellemző az I/O-korlátozott terhelésekre, ahol a szálak folyamatosan blokkolódnak a lemezen vagy a hálózaton.

Ha valami nem stimmel, folytassa a perf record -F 99 -g -p PID -- sleep 30. A -F 99 99 Hz-en vesz mintákat, ami elegendő a forró függvények megtalálásához, és elkerüli a szinkronizálást a kernel időzítőjével olyan kerek számoknál, mint a 100 Hz. A -g flag rögzíti a hívási gráfokat, így perf report megmutathassa, melyik útvonalak felelősek egy függvényen belül.

Az perf reportaz Overhead oszlop a teljes mintavételek arányát mutatja. Magas overhead _int_malloc vagy memcpy jelentős allokációt jelent. A saját függvényeinek egyikében jelentkező magas overhead az a hotspot, amit keresett.

Ha függvénynevek helyett hexadecimális címeket lát, akkor a bináris fájl lecsupaszított, vagy hiányoznak a hibakeresési szimbólumok. Telepítse a megfelelő -dbg csomagot, vagy fordítsa újra a bináris fájlt -g.

Gyakorlati munkafolyamat egy élő szerveren

Egy forgalmas szerveren bekövetkező valós incidens esetén a rutin a következőképpen néz ki:

1. Először olcsó eszközökkel ellenőrizze a tünetet: top, vmstat, iostat. Ha virtuális gépen dolgozik, ellenőrizze a st (steal) oszlopot. Ha az érték 5% felett van, az azt jelenti, hogy a hipervizor a szűk keresztmetszet, nem a kódja.
2. Ha a CPU-terhelés magas, futtassa perf top parancsot néhány másodpercig, majd a perf record -F 99 -g -p PID -- sleep 30 a problémás folyamatra. Egy 30 másodperces rögzítés 99 Hz-en körülbelül 1,7 MB adatot eredményez.
3. Ha a folyamat lefagyott, lassú vagy hibákat jelez, futtassa a strace -c -p PID parancsot tíz másodpercig, és olvassa el az összefoglalót. Ha egy rendszerhívás-kategória dominál, szűkítse le a strace -e trace=GROUP -T -p PID.
4. Amikor megtalálta a gyanús rendszerhívást vagy függvényt, válassza le a folyamatot. Ne hagyja a szerszámokat a termelési környezetben futni tovább, mint amennyire feltétlenül szükséges.

Két figyelmeztetés. strace A kimenet tartalmazhat környezeti változókat, fájlútvonalakat és a socketekből olvasott bájtokat, ezért tisztítsa meg a naplókat, mielőtt megosztaná őket a csapatán kívül. Ha pedig rendszeresen fogja ezt csinálni, nézze meg bpftrace és a szélesebb körű eBPF eszközkészletet: ugyanolyan átláthatóság, 1% alatti overhead, eleve termelésre tervezve.

Ha olyan munkaterheléseket futtat, ahol fontos a mélyreható diagnosztikai hozzáférés, és a megosztott infrastruktúra nem jöhet szóba, nézze meg dedikált szervereinket.