vmstat w Linux – interpretacja r, b, si, so, wa, st krok po kroku

Przez /

vmstat daje jednocześnie obraz kolejek procesów, aktywności pamięci, swapu, I/O i CPU. Jest szczególnie użyteczny w awarii, gdy jeden ekran top nie mówi, czy system spowalnia procesor, dysk czy presja pamięci. Najważniejsze: interpretuj grupy pól razem i mierz w czasie.

1. Jak pobierać próbki

vmstat -y 1 15
vmstat -SM -y 2 10
vmstat -s | head -35

Przy wielu wersjach vmstat pierwszy raport zawiera średnią od startu systemu. Opcja -y pomija ten raport; jeśli nie jest dostępna, zignoruj pierwszą linię. Odczyt co sekundę służy diagnostyce krótkiego incydentu; dla trendów obserwuj dłużej i koreluj z ruchem aplikacji.

2. Procs – kolumny r i b

r opisuje zadania gotowe do pracy lub wykonywane. Porównuj trend z efektywnie dostępną liczbą CPU. r=1–2 na 8 CPU zwykle nie wskazuje na dużą kolejkę; r=15 stale na 4 CPU razem z wysokim us/sy sugeruje CPU bottleneck. b oznacza zadania zablokowane oczekujące na I/O. Rosnące b przy dużym wa lub PSI I/O kieruje diagnostykę w stronę dysku, NFS lub urządzeń blokowych. Próg r > liczba CPU jest sygnałem do sprawdzenia, nie samodzielnym alarmem.

3. Memory – swpd, free, buff, cache

swpd to zajęta przestrzeń swap (w jednostkach zależnych od opcji), a nie tempo swapowania. free nie mierzy całej pamięci możliwej do odzyskania: Linux utrzymuje cache. buff i cache pomagają rozpoznać wykorzystanie pamięci przez cache, ale do określenia zapasu użyj free -h i pola available.

4. Swap – si i so

si to dane wczytywane ze swap na sekundę, so – zapisywane do swap. swpd=4 GiB przy si=0, so=0 przez wiele minut nie dowodzi bieżącego problemu; to może być pamięć dawno odłożona do swap. Powtarzalne si i so (szczególnie wraz z opóźnieniami i wysokim PSI memory) to silniejszy argument za presją pamięci. Uwaga: jednostki raportowania zależą od wersji i opcji; nie nazywaj liczb automatycznie MiB/s.

5. I/O – bi i bo

bi i bo to transfery do i z urządzeń blokowych na sekundę. Wysokie bi/bo to aktywność, niekoniecznie przeciążenie. Dysk NVMe potrafi obsługiwać dużą przepustowość przy bardzo małym opóźnieniu; niskie transfery na przeciążonym systemie mogą współwystępować z losowym I/O, dużą liczbą drobnych żądań i wysokim await.

6. CPU – us, sy, id, wa, st

us – czas CPU użytkownika, sy – jądro, id – bezczynność, wa – czas oczekiwania na I/O, st – czas VM odebrany przez hipernadzorcę. Jeśli st utrzymuje się wysoko podczas pogorszenia usług, sprawdź hosta i limit CPU; jeśli sy rośnie nietypowo, zweryfikuj liczbę syscalli, sieć i storage. wa samo nie określa poziomu zapełnienia kolejki urządzenia.

7. Przykładowe odczyty i wnioski

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo    in   cs us sy id wa st
 9  0      0  42000  22000 730000   0    0     3    25  1500 9800 92  6  2  0  0
 1  6      0  80000  12000 700000   0    0   600   120  1200 3000  5  3 55 37  0
 4  1 210000  16000   9000  84000 750  890   300  130  2600 8600 45 10 20 24  1

Dane są fikcyjne. Wiersz pierwszy: duże r, prawie brak idle i małe b – prawdopodobne przeciążenie CPU (zależnie od liczby CPU). Drugi: dużo zablokowanych zadań i wysoki wait – sprawdź dysk/NFS i iostat. Trzeci: aktywne swap-in i swap-out, mało wolnej pamięci oraz oczekiwanie – podejrzenie presji RAM i możliwego thrashingu. To hipotezy, które trzeba potwierdzić dodatkowymi pomiarami.

8. Uzupełnij o presję i procesy

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io
pidstat -u -r -d 1 10
iostat -xz 1 10
free -h

PSI some avg10 mówi, przez jaki procent czasu przynajmniej jedno zadanie czekało na zasób w ostatnim 10-sekundowym oknie; full jest poważniejszym sygnałem, gdy wszystkie aktywne zadania były równocześnie zatrzymane (z wyjątkami systemowego CPU). Wynik 20 oznacza około 20% czasu z określonym rodzajem oczekiwania, a nie 20% CPU. Porównaj z opóźnieniami aplikacji.

9. Najczęstsze błędy

  • Nie oceniaj pojedynczej próbki zamiast trendu.
  • Nie utożsamiaj swpd z aktywnym swapowaniem; porównaj z si/so.
  • Nie uznawaj wysokiego b za awarię dysku bez sprawdzenia źródła I/O.
  • Nie traktuj dużego wa jako miernika %util.
  • Nie stawiaj progu alarmowego bez informacji o liczbie CPU, typie workloadu i tolerowanym czasie odpowiedzi.

Dokumentacja

Źródła: vmstat(8) i PSI. Artykuł nadrzędny: Diagnostyka wydajności Linux.

Przewijanie do góry