Diagnostyka wydajności Linux – CPU, RAM i I/O

Serwer „działa wolno” to jeden z najmniej precyzyjnych opisów awarii. Problem może wynikać z CPU, pamięci, swapu, dysków, sieci, blokad aplikacji albo pojedynczego procesu. Zamiast zaczynać od losowego restartu, warto przejść przez kilka prostych pomiarów i ustalić, który zasób naprawdę jest wąskim gardłem.

Poniżej znajduje się schemat diagnostyczny nastawiony na typową administrację serwerem Linux. Nie chodzi o benchmark, tylko o odpowiedź na pytanie: dlaczego system jest teraz wolny?

1. Zaczynam od load average

uptime
cat /proc/loadavg

Load average nie jest bezpośrednio procentem użycia CPU. Pokazuje liczbę zadań oczekujących na wykonanie lub znajdujących się w stanie nieprzerywalnym, często związanym z I/O. Dlatego wysoki load przy niskim CPU może wskazywać np. na problem z dyskiem.

Wynik trzeba odnosić do liczby logicznych CPU:

nproc
lscpu

2. top lub htop – szybki obraz sytuacji

top

Patrzę przede wszystkim na użycie CPU, load, ilość wolnej pamięci, swap oraz procesy z największym %CPU i %MEM. W top szczególnie ważny jest parametr wa — I/O wait. Duża wartość może oznaczać, że CPU czeka na operacje dyskowe.

Jeżeli jeden proces stale zużywa cały rdzeń, to inny problem niż sytuacja, gdy wszystkie procesy prawie nic nie robią, ale system ma duży I/O wait.

3. vmstat – jedno z najbardziej użytecznych poleceń

vmstat 1 10

Pierwsza linia zawiera wartości od uruchomienia systemu, dlatego przy analizie patrzę głównie na kolejne próbki. Kluczowe pola:

r – procesy oczekujące na CPU
si / so – swap in / swap out
us / sy – czas CPU użytkownika i kernela
wa – czas oczekiwania na I/O
id – bezczynność CPU

4. Pamięć – nie patrz tylko na pole free

free -h
cat /proc/meminfo | head -30

Linux wykorzystuje wolny RAM jako cache, dlatego mała wartość free sama w sobie nie jest problemem. Znacznie ważniejsze jest available oraz to, czy system zaczyna aktywnie korzystać ze swapu.

Jeżeli vmstat pokazuje regularne wartości si/so, a aplikacje reagują skokowo, może to być realna presja pamięciowa.

5. Czy zadziałał OOM killer

journalctl -k -b | grep -Ei "oom|out of memory|killed process"

Przy braku pamięci kernel może zakończyć proces. Po restarcie aplikacji problem wygląda czasem jak „losowa awaria”, dlatego warto zawsze sprawdzić log kernela.

6. Dysk i I/O – iostat

iostat -xz 1 10

Polecenie pochodzi zwykle z pakietu sysstat. Przy dyskach interesują nas m.in. opóźnienia, długość kolejki oraz wykorzystanie urządzenia. Nie ma jednej uniwersalnej wartości, po której można powiedzieć „dysk jest przeciążony” — NVMe i klasyczny HDD mają zupełnie inne charakterystyki.

Patrzę na trend: czy opóźnienie rośnie, czy kolejka jest stale długa i czy problem występuje dokładnie w czasie spowolnienia aplikacji.

7. Który proces generuje I/O

pidstat -d 1 10
pidstat -r 1 10
pidstat -u 1 10

pidstat pozwala obserwować procesy osobno dla CPU, pamięci i I/O. Jest bardzo przydatny wtedy, gdy ogólne statystyki pokazują problem, ale nie wiadomo, która aplikacja go powoduje.

8. Miejsce na filesystemie i inode

df -hT
df -ih

Pełny filesystem to oczywisty problem, ale równie łatwo przeoczyć wyczerpanie inode. System może mieć jeszcze gigabajty wolnego miejsca i jednocześnie nie być w stanie utworzyć kolejnego pliku.

Jeżeli problem dotyczy partycji, LVM albo rozbudowy storage, przydatne będą również materiały Zarządzanie dyskami i pamięcią masową i Zarządzanie LVM.

9. Sieć – czy aplikacja czeka na połączenia

ss -s
ss -tulpn
ip -s link
ip route

Wysokie opóźnienia aplikacji nie zawsze oznaczają problem CPU lub dysku. Jeżeli usługa czeka na bazę, API lub storage po sieci, lokalny serwer może wyglądać zupełnie zdrowo.

Na początek sprawdzam liczbę połączeń, błędy na interfejsach i routing. Więcej poleceń znajduje się w artykule Zarządzanie siecią w systemie Linux.

10. Szybka procedura „serwer jest wolny”

uptime
nproc
free -h
vmstat 1 5
iostat -xz 1 5
pidstat -u -r -d 1 5
df -hT
df -ih
ss -s

Taki zestaw w kilka minut pozwala odpowiedzieć, czy problem jest związany głównie z CPU, pamięcią, I/O, przestrzenią dyskową czy siecią. Dopiero później przechodzę do narzędzi specyficznych dla konkretnej aplikacji.

11. Czego nie robić

nie oceniaj pamięci wyłącznie po polu free
nie traktuj load average jako procentu CPU
nie zakładaj, że 100% wykorzystania dysku zawsze oznacza awarię
nie restartuj aplikacji przed zapisaniem podstawowych metryk — restart może usunąć najcenniejszy ślad
nie diagnozuj tylko jednego zasobu; problemy często są łańcuchem zależności

Podsumowanie

Dobra diagnostyka wydajności polega przede wszystkim na zawężaniu problemu. Najpierw ogólny stan, potem CPU, pamięć i I/O, następnie konkretny proces i zależności zewnętrzne. Kilka prostych narzędzi — vmstat, iostat, pidstat, ss i journal — w większości przypadków daje więcej niż losowe strojenie parametrów systemu.