strace i perf do rozwiązywania problemów w systemie Linux

Gdy serwer Linux działa wolno, ulega awariom lub nadmiernie obciąża procesor, a logi aplikacji nie wyjaśniają przyczyny, dwa narzędzia pozwalają wypełnić większość luk. strace pokazuje, o co proces prosi jądro. perf pokazuje, na co procesor poświęca swój czas. Razem odpowiadają na pytania „dlaczego się zawiesił” i „co robi”, których żadne inne narzędzie nie rozwiązuje tak tanio.

W tym poście omówiono, kiedy sięgać po każde z tych narzędzi, jak je zainstalować, jakie polecenia faktycznie uruchomić oraz jak utrzymać obciążenie na rozsądnym poziomie na serwerze produkcyjnym.

Kiedy używać strace, a kiedy perf

Różnica jest prosta. Użyj perf , gdy procesor jest zajęty i chcesz wiedzieć, która funkcja jest za to odpowiedzialna. Użyj strace gdy proces zawiesza się, ulega awarii, zwraca dziwne błędy lub zachowuje się w sposób, którego logi nie wyjaśniają.

perf pobiera próbki liczników sprzętowych jądra z konfigurowalną częstotliwością, więc obciążenie wynosi zazwyczaj poniżej 1% i można go bezpiecznie uruchamiać w środowisku produkcyjnym. strace przechwytuje każde wywołanie systemowe poprzez ptrace, co może spowolnić proces docelowy od 10 do 100 razy. Używaj go oszczędnie w systemach produkcyjnych i zawsze z filtrami.

Instalacja strace i perf

Oba narzędzia znajdują się w standardowych repozytoriach. strace opiera się na ptrace syscall, który od lat jest częścią każdego nowoczesnego jądra. perf korzysta z perf_events i wymaga pakietu zgodnego z używanym jądrem.

W systemie Ubuntu lub Debian:

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

W systemach RHEL, AlmaLinux lub Fedora:

sudo dnf install strace perf

Bit $(uname -r) liczy się wersja. Plik binarny perf skompilowany pod inną wersję jądra generuje mylące wyniki i może w tle pomijać zdarzenia. Sprawdź za pomocą perf --version i strace -V po instalacji.

Aby perf wyświetlał nazwy funkcji zamiast adresów szesnastkowych, potrzebne są symbole debugowania. Zainstaluj odpowiedni plik -dbg lub -debuginfo (na przykład libc6-dbg w systemie Debian) i skompiluj własne pliki binarne za pomocą -g w GCC.

W kontenerach strace potrzebuje --cap-add=SYS_PTRACE i perf wymaga --cap-add=SYS_ADMIN podczas uruchamiania za pomocą Docker. Bez tych ograniczeń narzędzia zawodzą w sposób przypominający błędy.

Śledzenie wywołań systemowych za pomocą strace

Uruchomienie strace command śledzi proces od momentu uruchomienia. Aby dołączyć do uruchomionego procesu, użyj strace -p PID. W przypadku procesów wielowątkowych lub tworzących procesy potomne należy dodać -f , aby śledzić procesy potomne, w przeciwnym razie przegapisz większość aktywności.

Wiersze wyjścia kończą się wartością zwracaną. -1 ENOENT oznacza, że plik, o który poprosił proces, nie istnieje. -1 EACCES oznacza uprawnienia. Te dwa błędy same w sobie stanowią zaskakująco dużą część błędów produkcyjnych.

Najbardziej przydatnym parametrem jest -e trace=GROUP, która ogranicza wyjście do określonej kategorii wywołań systemowych i pozwala utrzymać poziom szumu na akceptowalnym poziomie.

Na obciążonym serwerze zacznij od strace -c -p PID przez dziesięć lub dwadzieścia sekund. Flaga -c flaga wyświetla podsumowanie liczby wywołań systemowych, całkowitego czasu i błędów po odłączeniu. Dzięki temu wiesz, którą kategorię warto dokładniej sprawdzić, bez zalewania terminala informacjami. Następnie podłącz się ponownie z wąskim filtrem.

Inne flagi, o których warto wiedzieć: -T rejestruje czas spędzony na każdym wywołaniu, -Z wyświetla tylko nieudane wywołania oraz -o file zapisuje do pliku dziennika zamiast do terminala, co jest znacznie szybsze w przypadku hałaśliwego procesu.

Profilowanie procesora za pomocą perf

perf posiada cztery polecenia, z których będziesz korzystać najczęściej.

Zacznij od perf stat -p PID , aby uzyskać szybki przegląd. Liczby, na które należy zwrócić uwagę:

• IPC (instrukcje na cykl) poniżej 1,0: procesor się zawiesza, zazwyczaj podczas dostępu do pamięci.
• Wysoka liczba nieudanych prób odczytu z pamięci podręcznej (LLC-load-misses): zestaw roboczy nie mieści się w pamięci podręcznej, więc procesor czeka na pamięć RAM.
• Duża liczba przełączeń kontekstu: typowe dla obciążeń związanych z operacjami wejścia/wyjścia, gdzie wątki ciągle blokują się na dysku lub w sieci.

Jeśli coś wygląda na nieprawidłowe, sprawdź perf record -F 99 -g -p PID -- sleep 30. -F 99 próbkuje z częstotliwością 99 Hz, co wystarcza do znalezienia gorących funkcji i pozwala uniknąć synchronizacji z zegarem jądra przy okrągłych wartościach, takich jak 100 Hz. Flaga -g flaga przechwytuje wykresy wywołań, dzięki czemu perf report może pokazać, które ścieżki do funkcji są za to odpowiedzialne

W perf reportkolumna „Overhead” przedstawia udział w całkowitej liczbie próbek. Wysokie obciążenie w _int_malloc lub memcpy oznacza intensywną alokację. Wysokie obciążenie w jednej z twoich własnych funkcji to ten punkt newralgiczny, którego szukałeś.

Jeśli zamiast nazw funkcji widzisz adresy szesnastkowe, plik binarny jest pozbawiony informacji o symbolach lub brakuje symboli debugowania. Zainstaluj pasujący -dbg pakiet lub skompiluj plik binarny ponownie z -g.

Praktyczny przebieg pracy na serwerze produkcyjnym

W przypadku rzeczywistego incydentu na obciążonym serwerze procedura wygląda następująco:

1. Najpierw potwierdź objawy za pomocą niedrogich narzędzi: top, vmstat, iostat. Jeśli korzystasz z maszyny wirtualnej, sprawdź kolumnę st kolumnę (steal). Wartość powyżej 5% oznacza, że wąskim gardłem jest hiperwizor, a nie Twój kod.
2. Jeśli obciążenie procesora jest wysokie, uruchom perf top przez kilka sekund, a następnie perf record -F 99 -g -p PID -- sleep 30 dla procesu, który sprawia kłopoty. 30-sekundowy zapis przy częstotliwości 99 Hz generuje około 1,7 MB danych.
3. Jeśli proces zawiesił się, działa wolno lub zwraca błędy, uruchom strace -c -p PID przez dziesięć sekund i przeczytaj podsumowanie. Jeśli dominuje jedna kategoria wywołań systemowych, zawęź zakres za pomocą strace -e trace=GROUP -T -p PID.
4. Po znalezieniu podejrzanego wywołania systemowego lub funkcji, odłącz się. Nie pozostawiaj żadnego z narzędzi uruchomionego w środowisku produkcyjnym dłużej, niż to konieczne.

Dwa zastrzeżenia. strace Wynik może zawierać zmienne środowiskowe, ścieżki do plików oraz bajty odczytane z gniazd, więc oczyść logi przed udostępnieniem ich poza zespołem. A jeśli zamierzasz to robić regularnie, w następnym kroku przyjrzyj się bpftrace i szerszy zestaw narzędzi eBPF jako następny krok: ten sam rodzaj wglądu, obciążenie poniżej 1%, stworzony od początku z myślą o środowisku produkcyjnym.

Jeśli obsługujesz obciążenia, w których istotny jest głęboki dostęp diagnostyczny, a infrastruktura współdzielona nie wchodzi w grę, zapoznaj się z naszą ofertą serwerów dedykowanych.