top i htop – analiza CPU, procesów, pamięci i wąskich gardeł

Przez /

top i htop odpowiadają na dwa pytania: co dzieje się z serwerem teraz i które procesy mogą za to odpowiadać. Sam odczyt wysokiego %CPU albo małej kolumny free nie wystarcza do diagnozy. Trzeba rozróżnić zużycie, konkurencję o zasób i realny wpływ na użytkownika.

1. Zbierz próbki, nie pojedynczy ekran

top -b -n 5 -d 2 -w 180
top -H -p 1234
ps -eo pid,ppid,stat,pcpu,pmem,rss,vsz,comm --sort=-pcpu | head -20
cat /proc/pressure/cpu

Pierwszy zrzut w top może bazować na skumulowanych statystykach CPU. Patrz na kolejne próbki; dla awarii zapisuj czas wystąpienia, PID, stan procesu i interwał. -H pokazuje wątki danego procesu. W htop można włączyć widok per CPU, sortowanie po CPU/RAM i drzewo procesów; dokładne klawisze zależą od wersji programu.

2. Jak czytać %Cpu(s): us, sy, ni, id, wa, hi, si, st

  • us – praca kodu użytkownika; 90% i opóźnienia mogą oznaczać CPU-bound workload, ale 90% bez opóźnień nie musi być problemem.
  • sy – praca jądra; nietypowo wysoka wartość może wiązać się z syscallami, siecią lub systemem plików. Wymaga dalszej analizy.
  • id – bezczynność; duże id przy wolnej aplikacji kieruje uwagę na czekanie, blokady lub zależności zewnętrzne.
  • wa – czas CPU zaliczony jako oczekiwanie na I/O; nie jest to procent zajętości dysku, szczególnie na wielu CPU.
  • st – czas odebrany VM przez hypervisor; utrzymujące się kilka–kilkanaście procent razem ze spowolnieniem to sygnał do kontroli hosta lub przydziału vCPU.
  • hi/si – obsługa przerwań sprzętowych i programowych; wzrost może wskazać ruch sieciowy lub sterownik.
  • ni – praca procesów ze zmienionym nice; sama wartość nie jest awarią.

3. Ile %CPU oznacza problem?

Dla systemu wielordzeniowego nie istnieje jedna granica, po której zaczyna się awaria. W trybie Irix pojedynczy wielowątkowy proces może mieć 250% CPU: oznacza to w przybliżeniu wykorzystanie 2,5 logicznego CPU. W alternatywnym trybie Solaris wartości są normalizowane do sumy CPU. Dlatego przed oceną zobacz tryb wyświetlania, liczbę CPU i czy wysokie użycie ma związek z czasem odpowiedzi usługi. Trwałe 95–100% użycia dostępnego CPU przy rosnącym r i PSI sugeruje przeciążenie; pojedynczy proces 100% na maszynie 16 CPU nie musi oznaczać kłopotu.

4. VIRT, RES, SHR i %MEM – czego nie wolno utożsamiać

VIRT to wirtualna przestrzeń adresowa: rezerwacje, mapowania i biblioteki. Nie jest równa zajętemu RAM. RES (zbliżone do RSS) to fizycznie rezydujące strony, ale obejmuje także współdzieloną pamięć; sumowanie RES wszystkich procesów zawyża całkowite zużycie. SHR jest tylko przybliżoną miarą stron potencjalnie dzielonych. %MEM zwykle odnosi RES do pamięci fizycznej hosta, nie limitu cgroup.

cat /proc/1234/status | grep -E 'VmRSS|VmSize|VmSwap|Threads'
cat /proc/1234/smaps_rollup 2>/dev/null | head -30
free -h
systemctl show nginx -p MemoryCurrent -p MemoryMax

Do precyzyjnego rozliczenia pamięci procesów wykorzystaj Pss z smaps_rollup, która dzieli koszt współdzielonych stron pomiędzy procesy. Gdy kontener ma limit 512 MiB, kieruj uwagę na memory.current i memory.max, a nie tylko %MEM liczony dla 64 GiB RAM hosta.

5. Stany procesów: R, S, D, T, Z

  • R – wykonywany lub gotowy do wykonania; dużo R i wysoki CPU pressure sugerują kolejkę CPU.
  • S – sen przerywalny, normalny m.in. dla usług oczekujących na żądania.
  • D – oczekiwanie nieprzerywalne, często na I/O; duża liczba D i niski CPU wskazują na inny problem niż CPU.
  • T – proces zatrzymany (np. przez sygnał lub debugger).
  • Z – zombie; sporadyczny wpis może być krótkotrwały, narastająca liczba wymaga sprawdzenia procesu rodzica.

6. Trzy charakterystyczne scenariusze

A: us=94%, id=2%, wa=0% i wiele wątków aplikacji w R: przeanalizuj profil CPU i ruch żądań. B: id=75%, wa=19%, dużo D: przejdź do iostat, vmstat i storage. C: st=18% w VM, host mało obciążony z punktu widzenia aplikacji: sprawdź steal i ograniczenia hipernadzorcy. To przykłady ilustracyjne, nie sztywne normy alarmowe.

7. Typowe pułapki diagnostyki

Nie porównuj %CPU z dwóch różnych trybów top. Nie utożsamiaj RAM wolnego z RAM dostępnego. Nie obwiniaj procesu z największym RES bez weryfikacji PSS i pamięci współdzielonej. Nie uznawaj wartości wa=0 za dowód, że storage nie jest problemem – obserwuj też latencję I/O aplikacji i PSI.

Dokumentacja i kontekst

Sprawdź top(1) i PSI. Artykuł przeglądowy: Diagnostyka wydajności Linux.

Przewijanie do góry