Jak czytać iostat, vmstat i sar, żeby namierzyć wąskie gardła I/O

Cel diagnozy: szybkie namierzanie wąskich gardeł I/O bez drogich narzędzi

Intencja jest prosta: sprawdzić, czy to faktycznie dysk (I/O) spowalnia system, zrobić to szybko, bez instalowania ciężkich agentów APM i bez tygodniowej nauki skomplikowanych interfejsów. iostat, vmstat i sar są w większości dystrybucji Linux dostępne od ręki albo do doinstalowania jednym poleceniem, a przy odrobinie wprawy wystarczają do zdiagnozowania przynajmniej 80–90% realnych problemów wydajnościowych.

Dobrze ustawione i właściwie czytane narzędzia z pakietu sysstat (iostat, sar) plus prosty vmstat pozwalają szybko odpowiedzieć na kluczowe pytania: czy problem leży w dysku, pamięci, CPU, czy w samej aplikacji. Bez tej wiedzy łatwo przepalić budżet na niepotrzebne dyski czy serwery, gdy tak naprawdę wystarczyłoby skorygować konfigurację lub zaplanować zadania w czasie.

Frazy powiązane: analiza iostat w praktyce, interpretacja vmstat krok po kroku, wykorzystanie sar do historii obciążenia, diagnostyka wąskich gardeł dysku, kolejki I/O i opóźnienia, monitoring wydajności Linux bez agentów, proste metody profilowania I/O, korelacja CPU pamięci i dysku, troubleshooting storage pod obciążeniem, tanie sposoby monitoringu wydajności, czytanie metryk systemowych bez magii.

Po co w ogóle zaglądać w iostat, vmstat i sar

Objawy problemów I/O widziane oczami użytkownika i administratora

Problemy z I/O rzadko krzyczą wprost: „dysk jest za wolny”. Częściej widać jedynie efekty uboczne, które łatwo zrzucić na „słaby serwer” albo „ciężką aplikację”. Typowe symptomy to:

• nagłe lagi w aplikacji webowej przy większej liczbie użytkowników, mimo że CPU w top/htop jest „ledwie ruszone”;
• czasem wszystko działa szybko, a czasem nagle staje – użytkownicy mówią o „zamrożeniu” systemu na kilka–kilkadziesiąt sekund;
• częste timeouty zapytań do bazy danych, zwłaszcza przy raportach i backupach;
• długi czas startu procesów lub komend, które wcześniej wykonywały się błyskawicznie (np. ls w dużych katalogach, git status na dużych repozytoriach);
• system reaguje na ssh z opóźnieniem, konsola „ciągnie się”, kursor pojawia się z poślizgiem.

Od strony administratora pojawiają się takie obserwacje jak wysokie iowait w top, dziwne skoki obciążenia load average bez dużego zużycia CPU, agresywne użycie swapu czy procesy wiszące w stanie D (uninterruptible sleep). Samo oglądanie CPU i RAM w top/htop rzadko pozwala zrozumieć, czy to dysk jest gardłem, czy CPU, czy może brak pamięci.

Dlaczego same metryki CPU i RAM to za mało

top i htop świetnie pokazują, kto „zjada” CPU i RAM, ale w kwestii I/O są bardzo ograniczone. Widać tam co najwyżej:

• procent CPU w iowait (wa),
• stan procesów (D – uninterruptible sleep, zwykle I/O),
• ilość wolnej pamięci i użycie swapu.

Nie da się jednak na tej podstawie odpowiedzieć na kluczowe pytania: który dysk, który wolumen, jakie są opóźnienia, jak duża jest kolejka I/O. Widzimy „ból” systemu, ale nie widać jego źródła. To klasyczna sytuacja: CPU ma dużo „idle”, ale użytkownicy narzekają na wolne działanie. Bez narzędzi takich jak iostat i vmstat łatwo zrzucić winę na sieć, aplikację albo „magiczne” problemy.

Równie mylące są surowe dane o pamięci z free czy top: wysoki cache wygląda jak „zajęta pamięć”, podczas gdy to wręcz poprawia wydajność I/O. vmstat dopiero pokazuje, jak wygląda realne ciśnienie na pamięć i czy sprzęt zaczyna ratować się swapowaniem.

Kiedy wystarczy prosty monitoring, a kiedy sięgnąć po cięższą artylerię

iostat, vmstat i sar to narzędzia o bardzo dobrym stosunku efektu do wysiłku. W wielu środowiskach, szczególnie mniejszych i średnich, w zupełności wystarcza:

• okazjonalne odpalanie iostat i vmstat „na żywo” w trakcie incydentu,
• lekko skonfigurowany sar zbierający historię obciążenia,
• prosta korelacja tych danych z logami aplikacji lub bazy danych.

Droższe narzędzia – APM, bpftrace, perf, narzędzia profilujące konkretne bazy danych – wchodzą do gry, gdy:

• problem jest bardzo subtelny lub dotyczy głębokiej warstwy aplikacji,
• potrzebne są szczegółowe flamegraphy, trace’y system calls lub granulacja na poziomie funkcji w kodzie,
• masz środowisko o krytycznym SLA i budżet na zaawansowane monitorowanie.

W praktyce jednak, zanim zainwestuje się w drogie rozwiązania, ma sens wykorzystanie tego, co daje system za darmo: sysstat + vmstat + logi. To niewielki narzut na zasoby, a często wystarczy, by uzasadnić lub… obalić potrzebę kosztownego rozbudowywania storage’u.

Efekt vs wysiłek: co da się ugrać standardowymi narzędziami

iostat, vmstat i sar to klasyczne narzędzia „budżetowego pragmatyka”. Szybko się ich nauczyć, są lekkie, zaufane i zwykle już zainstalowane lub dostępne w repozytorium dystrybucji. Przy rozsądnym nakładzie pracy dają:

• identyfikację wąskich gardeł dysku (wysokie opóźnienia, kolejki, %util),
• rozróżnienie między „prawdziwym” brakiem RAM a błędną interpretacją cache’u,
• podstawową analizę historii obciążenia – kiedy były piki, jakie były parametry,
• twarde dane do rozmowy z dostawcą storage’u lub zespołem aplikacji.

Te narzędzia nie zrobią za administratora pełnego performance tuningu, ale pozwalają szybko zorientować się, czy problem w ogóle leży w I/O. Jeśli nie, znacznie zawężają pole dalszej analizy, co oszczędza czas i nerwy całego zespołu.

Szybkie odświeżenie podstaw: jak działa I/O w systemie operacyjnym

Synchroniczne vs asynchroniczne I/O oraz rola kolejek

Rozumienie wyników iostat i vmstat zaczyna się od pojęcia kolejki I/O i różnicy między I/O synchronicznym a asynchronicznym.

W uproszczeniu:

• I/O synchroniczne – proces wysyła żądanie (np. odczytaj plik) i czeka, aż ono się zakończy. W kodzie oznacza to zwykle blokujące wywołania read()/write(). W tym czasie proces może siedzieć w stanie D, a CPU ma wolne moce.
• I/O asynchroniczne – proces zleca operację (np. AIO, io_uring, niektóre biblioteki bazodanowe) i nie czeka bezczynnie. System sygnalizuje zakończenie operacji później, a proces może w międzyczasie robić coś innego.

System operacyjny nie wysyła każdego żądania wprost do dysku. Korzysta z kolejek I/O i algorytmów planowania (schedulery: mq-deadline, none, bfq i inne). To one decydują, w jakiej kolejności wykonywać operacje dyskowe, jak je grupować i optymalizować, aby skrócić czas ruchu głowicy (w HDD) lub sensownie zarządzać pasmem (w SSD i storage sieciowym).

To, co widać w iostat jako avgqu-sz lub aqu-sz, to średnia długość kolejki. Im wyższa, tym więcej operacji czeka w „poczekalni” do obsłużenia przez urządzenie. W praktyce wysoka kolejka plus wysokie opóźnienia oznaczają, że dysk nie wyrabia i zaczyna być wąskim gardłem.

Buforowanie, page cache, write-back i dirty pages

Linux agresywnie używa wolnej pamięci jako cache dyskowy (page cache). Pozwala to znacząco przyspieszyć odczyty: jeśli dane są już w pamięci, operacja I/O nie trafia do fizycznego dysku, tylko do RAM. W statystykach iostat czy vmstat wiele operacji, które aplikacja widzi jako „dyskowe”, w rzeczywistości kończy się w pamięci.

Dla zapisów sytuacja jest bardziej złożona. Większość zapisów działa w trybie write-back: aplikacja zapisuje dane, ale jądro systemu najpierw trzyma je w pamięci jako dirty pages i dopiero po pewnym czasie (lub przy wymuszeniu sync/fsync) wypycha je na fizyczne urządzenie. Dzięki temu aplikacja nie czeka na powolny dysk przy każdym zapisie. Jednak w statystykach I/O:

• chwilowo może być widać niski zapis na dysk mimo intensywnego zapisu w aplikacji, bo dane siedzą jeszcze w RAM,
• później pojawia się krótki, ale mocny „peak” I/O, gdy dirty pages są opróżniane.

Takie zachowanie utrudnia diagnozę, jeśli patrzy się wyłącznie na krótkie, pojedyncze wycinki z iostat. Dlatego przy problemach z I/O warto:

• łączyć iostat z vmstat (kolumny poświęcone io i swap),
• korzystać z sar, aby zobaczyć, jak w czasie rosło i spadało obciążenie.

Od logicznego I/O do fizycznych operacji na dysku

Procesy i aplikacje widzą pliki, katalogi, bazy danych. System plików widzi bloki, a dysk – sektory. Jedno zapytanie SQL może powodować dziesiątki, setki lub tysiące małych losowych operacji odczytu i zapisu. Z kolei duży sekwencyjny backup może być widoczny jako spójny, liniowy stream danych.

Dla diagnozy wąskich gardeł I/O istotne jest rozróżnienie:

• małe losowe I/O (np. OLTP, intensywna praca małej bazy, logi) – generuje wiele operacji r/s, w/s przy stosunkowo mniejszym throughput (rkB/s, wkB/s), mocno obciąża IOPS urządzenia,
• duże sekwencyjne I/O (backupy, skanowanie dużych tabel) – mniejsza liczba operacji, ale duży throughput, często saturuje pasmo dysku, ale niekoniecznie IOPS.

Wyniki iostat (szczególnie r/s, w/s, rkB/s, wkB/s, await, svctm, %util) pozwalają z grubsza ocenić, z którym typem obciążenia mamy do czynienia. To ważne, bo inne optymalizacje mają sens dla ruchu losowego (np. SSD, lepsze indeksy w bazie), a inne dla sekwencyjnego (planowanie okien backupu, priorytety I/O).

SSD, HDD i storage sieciowy – jak wpływają na metryki

Rodzaj sprzętu dyskowego znacząco zmienia interpretację wyników iostat, choć narzędzie samo o tym nie wie. Kilka różnic praktycznych:

• HDD: relatywnie wysokie opóźnienia (milisekundy), duża różnica między losowym a sekwencyjnym I/O, %util bliski 100% przy stosunkowo niewielkiej liczbie IOPS. await powyżej kilkudziesięciu milisekund to często już problem.
• SSD: dużo niższe opóźnienia (użytkowo często pojedyncze ms), lepiej znoszą losowe I/O, ale łatwiej je „zabić” intensywnym zapisem. %util szybko dochodzi do 100% przy wysokim obciążeniu, ale await może nadal być przyzwoity. Trzeba bardziej patrzeć na opóźnienia niż na sam %util.
• Storage sieciowy (NAS, SAN, chmura): oprócz samego dysku dochodzi opóźnienie sieciowe. await zawiera czas transportu po sieci i ewentualnych kolejek po drugiej stronie. Możliwa jest sytuacja, gdy lokalny CPU się nudzi, %util niskie, a await wysokie – problem leży po stronie sieci lub zdalnego storage’u.

Podczas czytania iostat progi alarmowe są inne dla różnych technologii. Dla wolnego HDD 20–30 ms może być akceptowalne, dla SSD już niekoniecznie. Z kolei w chmurze czy na SAN ważniejsza może być stabilność opóźnień niż sam %util.

iostat – fundament diagnozy I/O: uruchamianie i podstawowe tryby

Skąd wziąć iostat (pakiet sysstat) i jak go zainstalować

iostat pochodzi z pakietu sysstat. W wielu dystrybucjach jest zainstalowany domyślnie, ale jeśli go brakuje, instalacja jest szybka:

• Debian / Ubuntu: apt-get install sysstat
• RHEL / CentOS / Rocky / Alma: yum install sysstat lub dnf install sysstat
• SUSE: zypper install sysstat

Po instalacji iostat jest gotowy do użycia od razu. Do bieżącej diagnozy I/O nie potrzeba żadnej dodatkowej konfiguracji demona sysstat (ten jest potrzebny głównie dla sar). To proste narzędzie „on demand”: uruchamiasz, patrzysz, interpretujesz.

Podstawowa składnia i kiedy który tryb ma sens

Najczęściej używane warianty iostat to:

Najprostsze wywołania iostat w praktyce

Do diagnozy na żywo zwykle wystarczą dwa, trzy warianty polecenia. Zamiast ściany opcji lepiej mieć w głowie krótką ściągę:

• iostat -x 1 – rozszerzone statystyki dla wszystkich urządzeń, odświeżane co sekundę. Podstawowy „monitor na żywo”.
• iostat -xz 1 – to samo, ale pomija urządzenia bez aktywności. Mniej szumu, szybciej widać problematyczne dyski.
• iostat -dx 5 12 – szczegóły dla urządzeń blokowych, co 5 sekund, łącznie 12 próbek. Wygodne do późniejszego przejrzenia w logu lub przeklejenia do tiketa.

Domyślnie pierwsza linia wyniku pokazuje statystyki od startu systemu, a kolejne – dla danego interwału. Do diagnozy interesują nas właśnie te interwałowe wartości, bo oddają bieżące zachowanie storage’u, a nie uśredniony rok działania.

Przykładowy wynik iostat -xz 1 może wyglądać tak:

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s r_await w_await aqu-sz  svctm  %util
sda             10.00   50.00  1024.0  4096.0    0.00    1.00    5.00   10.00   0.60   1.00  6.00
sdb           1500.00  200.00 12000.0  2048.0   20.00    5.00   40.00   50.00  75.00   3.00 99.90

Już po jednym rzucie oka widać, że sdb jest przyduszony (wysokie opóźnienia i kolejka, %util blisko 100%), a sda żyje sobie spokojnie.

Przełączniki, które dają najwięcej za najmniejszy wysiłek

iostat ma długą listę opcji, ale z punktu widzenia diagnozy I/O na serwerze produkcyjnym wystarcza garstka. Sensowny zestaw „roboczy” wygląda tak:

• -x – rozszerzone statystyki (await, svctm, %util, kolejka). Bez tego iostat jest mało użyteczny.
• -z – ukrywa urządzenia, które nie wykonywały I/O w danym interwale. Mniej przewijania, większa czytelność.
• -d – pokazuje wyłącznie urządzenia blokowe (bez CPU). Dobre, gdy CPU mamy ogarnięte innymi narzędziami.
• -k lub -m – zmiana jednostek (KB/s lub MB/s). MB/s są wygodniejsze przy większych systemach.

Przykładowe kombo „na szybko” na większym serwerze:

iostat -dxmz 5

Co 5 sekund dostajemy tylko aktywne urządzenia, w MB/s, z rozszerzonym zestawem kolumn. Dobra równowaga między ilością danych a czytelnością.

Filtracja urządzeń i mapowanie LUN-ów do fizycznych dysków

Na maszynach z dużą liczbą dysków, LVM-em, multipathingiem lub storage’em SAN iostat potrafi zalać ekran dziesiątkami linii. Proces można uprościć na kilka tanich sposobów.

Po pierwsze – filtracja przez grep/egrep:

iostat -dx 2 | egrep 'Device|sdb|sdc'

Po drugie – w systemach z multipathingiem lepiej patrzeć na dm-* niż na fizyczne ścieżki sdX. Dane możemy połączyć z lsblk:

lsblk -o NAME,KNAME,SIZE,TYPE,MOUNTPOINT

Dzięki temu dm-2 nagle przestaje być anonimowym numerem z iostat i staje się konkretną grupą LVM pod np. /var/lib/postgresql. Ten krok często oszczędza sporo czasu w dyskusjach z zespołem aplikacji.

Czytanie iostat: kluczowe kolumny i praktyczne progi alarmowe

r/s, w/s, rkB/s, wkB/s – czy w ogóle jest ruch

Na początek trzeba odpowiedzieć na proste pytanie: czy dysk jest mocno używany. Dają to cztery podstawowe kolumny:

• r/s, w/s – liczba operacji odczytu i zapisu na sekundę (IOPS na urządzenie),
• rkB/s, wkB/s – przepustowość odczytu i zapisu w KB/s (lub MB/s przy -m).

Kilka orientacyjnych wniosków:

• duże r/s + małe rkB/s → wiele małych losowych odczytów (np. baza OLTP, intensywne logowanie),
• małe r/s + duże rkB/s → duże sekwencyjne odczyty (backup, skan całej tabeli),
• wysokie w/s + duże wkB/s → intensywne zapisy (backup, batch import, logi nawalające w jeden katalog).

Jeśli użytkownik skarży się na „mulenie” aplikacji, a r/s, w/s i przepustowość są śmiesznie niskie – problem najprawdopodobniej nie leży w storage’u (albo storage jest tak zapchany, że aplikacja prawie nie dochodzi do dysku, co i tak potwierdzą inne kolumny).

await i svctm – opóźnienia i czas obsługi

await to średni czas obsługi żądania I/O z punktu widzenia systemu (kolejka + sam dostęp do dysku). svctm to średni czas samej obsługi na urządzeniu. W nowszych wersjach jądra iostat może pokazywać tylko r_await i w_await, a svctm bywa nieco mylące, bo jego wartość zależy od algorytmu schedulera i implementacji.

Praktyczne progi, bardzo orientacyjne (trzeba je korygować pod konkretny sprzęt):

• HDD: await < 10–15 ms – komfortowo; 20–30 ms – zaczyna być odczuwalne; powyżej ~50 ms – zwykle realny problem.
• SSD lokalne: await < 2–3 ms – OK; 5–10 ms – coś zaczyna się dziać; powyżej kilkunastu ms – warto szukać przyczyny.
• Storage sieciowy: zakres jest szerszy, ale ważna jest stabilność. Skoki await do setek ms bywają bardziej bolesne niż stałe 20–30 ms.

Jeżeli await jest wielokrotnie większy niż svctm, oznacza to, że większość czasu operacje spędzają w kolejce, a nie na samym dysku. Tu wchodzą do gry metryki kolejki.

avgqu-sz / aqu-sz – długość kolejki i kiedy jest za długa

avgqu-sz (lub aqu-sz w nowszych wersjach) pokazuje średnią liczbę żądań oczekujących w kolejce na urządzenie w danym interwale. W skrócie – ilu klientów stoi pod drzwiami dysku.

Przybliżona interpretacja:

• kolejka bliska 0 – dysk z dużym zapasem, mało żądań czeka,
• kolejka kilku–kilkunastu operacji przy mocnym SSD lub macierzy – może być normalna, jeśli await jest niski,
• kolejka rosnąca do dziesiątek/przekraczająca 100 + wysokie await – klasyczne wąskie gardło I/O.

Sam wysoki aqu-sz bez wzrostu opóźnień może oznaczać, że system dobrze pipeline’uje I/O i urządzenie sobie radzi. Natomiast rosnąca kolejka razem z coraz wyższym await to już solidny sygnał, że urządzenie się dusi.

%util – pułapka „zabetonowanego” dysku

Kolumna %util bywa najczęściej cytowana i jednocześnie najbardziej zdradliwa. Pokazuje, przez jaki procent czasu w danym interwale urządzenie miało coś do roboty. 100% oznacza, że dysk był zajęty cały czas.

Na wolnych HDD to dość wiarygodny wskaźnik: jeśli %util przez dłuższą chwilę siedzi powyżej 90–95%, a await rośnie, dysk stał się butelką w szyjce. Na SSD i storage’u SAN sprawa jest mniej oczywista – %util bardzo szybko dochodzi do 100%, ale przy rozsądnych opóźnieniach nie musi to oznaczać tragedii.

Bezpieczniejszy sposób myślenia:

• wysokie %util + wysokie await → faktyczne przeciążenie,
• wysokie %util + niskie await → urządzenie pracuje pełną parą, ale wydajnie (często OK),
• niskie %util + wysokie await → podejrzenie problemu sieciowego (przy NAS/SAN) lub ograniczeń wyżej (np. throttling w hypervisorze, cgroup, kontroler).

W praktyce %util powinno się traktować jako „lampkę kontrolną”, ale diagnozę opierać bardziej na opóźnieniach i kolejce.

rrqm/s, wrqm/s i %merge – jak kernel grupuje żądania

rrqm/s i wrqm/s pokazują liczbę odczytów/zapisów na sekundę, które zostały skonsolidowane (request merged) przez schedulera. %rrqm i %wrqm mówią, jaki procent wszystkich żądań udało się zmergować.

Duży %rrqm/%wrqm przy sekwencyjnym I/O jest zjawiskiem pozytywnym – kernel umie połączyć sąsiadujące bloki w większe operacje. Małe wartości przy teoretycznie sekwencyjnych zadaniach (np. backup) mogą sugerować, że coś po drodze fragmentuje ruch (np. nadmiernie pofragmentowany filesystem, dziwny wzorzec odczytu aplikacji).

Przykładowe scenariusze z iostat i co z nich wynika

Typowe układanki, które powtarzają się w praktyce:

• Mała baza na HDD, końcówka miesiąca: r/s wysokie, rkB/s umiarkowane, await rośnie, %util rośnie do 100%, kolejka skacze. System „staje” o 8:00 rano. Rozwiązanie budżetowe: przeniesienie tylko woluminów z danymi bazy na SSD lub wydzielenie intensywnego raportowania na replikę.
• Serwer backupu: niskie IOPS, ogromne MB/s, %util 100%, await umiarkowane. System jedzie pasmem. Realny problem pojawia się, gdy backup dzieli dyski z logami aplikacji i tym samym wąskim oknem czasowym.

Tego typu wzorce, raz rozpoznane, bardzo przyspieszają każdą kolejną diagnozę. Nie trzeba wtedy analizować każdej kolumny po kolei – oko samo wyłapuje, czy obrazek bardziej przypomina OLTP, backup, czy klasyczne „mielimy swapa”.

vmstat – brakujące informacje: pamięć, kolejki procesów i swap

Podstawowe uruchomienie vmstat pod kątem I/O

vmstat pokazuje przekrojowo CPU, pamięć, kolejki procesów i podstawowe statystyki I/O. Do codziennej pracy wystarcza prosty wzór:

vmstat 1

Podobnie jak w iostat, pierwsza linia to dane od startu systemu, a kolejne – interwałowe. W większości przypadków interesują nas właśnie te „lecące” linie. Dla bardziej czytelnej analizy da się też użyć:

vmstat 2 20

co da 20 próbek co 2 sekundy. Można je potem zrzucić do pliku i spokojnie przeanalizować poza produkcją.

Rubryka procs: r i b – kto czeka na CPU, a kto na I/O

Pierwsza kolumna, na którą opłaca się rzucić okiem, to sekcja procs:

• r – liczba procesów gotowych do uruchomienia (kolejka na CPU),
• b – procesy w stanie nieprzerywalnym (zwykle I/O wait, ale również inne „twarde” blokady).

Jeśli r jest konsekwentnie wyższe od liczby dostępnych CPU, a I/O wygląda spokojnie – mamy problem CPU. Jeśli r jest niewielkie, za to b rośnie, a iostat pokazuje wysokie opóźnienia i kolejki – winowajcą jest dysk lub storage.

Niewielka liczba procesów w stanie b jest normalna, szczególnie na systemach z intensywnym I/O. Grubszy temat zaczyna się, gdy b przez dłuższy czas rośnie do wartości wielokrotnie większych niż liczba CPU, a użytkownicy zgłaszają „przywieszki”.

Pamięć w vmstat: free, buff, cache i aktywny swap

Sekcja memory w vmstat bywa źródłem wielu nieporozumień, szczególnie gdy ktoś patrzy tylko na „free”. Dla diagnozy I/O dużo ważniejsze jest to, czy system aktywnie używa swapa, niż to, czy free jest małe.

Kluczowe wartości:

• free – pamięć niewykorzystana w ogóle,
• buff – buffery blokowe (metadata filesystemów, buforowanie write),
• cache – page cache, czyli cache danych plików.

Na zdrowym serwerze Linux free bywa niskie, a buff+cache wysokie – to dobrze. Problemy zaczynają się, gdy pojawia się intensywna aktywność swapu w sekcji swap (si, so).

si, so – kiedy swap faktycznie boli

W sekcji swap vmstat pokazuje dwie krytyczne kolumny:

Najczęściej zadawane pytania (FAQ)

Skąd mam wiedzieć, że problem wydajności to faktycznie I/O, a nie CPU albo RAM?

Dobry punkt startowy to proste porównanie kilku rzeczy naraz: w top/htop CPU jest w większości „idle”, użytkownicy narzekają na lagi, a widać sporo procesów w stanie D (uninterruptible sleep). To klasyczny sygnał, że procesy czekają na dysk, a nie na CPU.

Drugi krok to odpalenie iostat i vmstat. Jeśli:

• w iostat widać wysokie opóźnienia (await) i wysokie %util dla jednego z dysków lub wolumenów,
• w vmstat w kolumnach si/so pojawia się realne swapowanie i rośnie ilość procesów blokujących się na I/O,

to z dużym prawdopodobieństwem wąskie gardło leży w I/O lub w pamięci, a nie w samym CPU.

Jak szybko sprawdzić, czy dysk jest „wąskim gardłem” za pomocą iostat?

Najprostszy, „budżetowy” sposób: uruchom iostat -x 1 w trakcie, gdy system jest wolny z punktu widzenia użytkowników. Obserwuj konkretne urządzenia (np. sda, nvme0n1, dm-0), a nie tylko sumę.

Zwróć uwagę na trzy rzeczy:

• %util blisko 100% przez dłuższy czas – dysk jest ciągle zajęty, kolejka się nie opróżnia,
• await / r_await / w_await – jeśli rosną do dziesiątek lub setek milisekund, użytkownicy zaczną to odczuwać jako lagi,
• avgqu-sz / aqu-sz – jeśli kolejka stale jest „gruba” i rośnie wraz z obciążeniem, urządzenie nie wyrabia.

Jeżeli wszystkie trzy parametry idą w górę przy obciążeniu i korelują z lagami w aplikacji, masz mocny argument, że to storage jest wąskim gardłem.

Po co używać vmstat, skoro mam top/htop i widzę CPU oraz pamięć?

top/htop pokazują, kto zjada CPU i RAM, ale słabo oddają dynamikę systemu. vmstat pokazuje „puls” systemu: ruch do/z swapu, długość kolejek, blokujące się procesy, aktywność I/O w czasie, a nie tylko stan „tu i teraz”.

Prosty przykład: w top widzisz niby dużo wolnego RAM, a użytkownicy narzekają na lagi. vmstat może pokazać:

• ciągłe, małe wartości si/so – system stale coś przerzuca do swapu i z powrotem,
• wysokie wartości w kolumnie b (blocked) – sporo procesów czeka na I/O,
• spadek „free” przy jednoczesnym wzroście cache – system agresywnie buforuje I/O.

To pozwala rozróżnić, czy potrzebujesz więcej RAM, lepszego storage, czy raczej korekty konfiguracji (np. zadań backupowych).

Do czego przydaje się sar i kiedy warto go skonfigurować?

sar jest idealny, gdy problem „pojawia się i znika”, a ty patrzysz na serwer już po fakcie. Pozwala cofnąć się w czasie i sprawdzić, jakie były parametry CPU, I/O, pamięci czy sieci o konkretnej godzinie, bez ciężkich agentów APM.

Na start wystarczy:

• włączyć zbieranie podstawowych statystyk (CPU, I/O, pamięć) w pakiecie sysstat,
• ustawić częstotliwość próbkowania na rozsądnym poziomie (np. co 1–5 minut),
• trzymać dane choćby z kilku dni lub tygodni, zależnie od wielkości dysków.

To tani sposób, żeby podczas zgłoszenia „wczoraj o 14:00 wszystko stanęło” sprawdzić, czy wtedy skoczyło I/O, load czy np. iowait, zamiast zgadywać.

Jak odróżnić „brak RAM” od normalnego użycia cache przez Linuxa?

W free/top „zajęta” pamięć wygląda groźnie, ale Linux używa wolnego RAM jako cache dyskowy. Sam wysoki cache to dobra rzecz – oznacza mniej realnych odwołań do dysku. Problem zaczyna się, gdy system musi często korzystać z swapu.

Żeby to rozróżnić:

• sprawdź w vmstat kolumny si/so – jeśli są stale >0 pod obciążeniem, system ratuje się swapowaniem,
• obserwuj opóźnienia i/o w iostat; jeśli rosną razem z ruchem do swapu, brakuje pamięci na working set aplikacji,
• porównaj to z obciążeniem aplikacji (logi, zapytania do bazy) – może prostsze będzie zoptymalizowanie zapytań lub cache’u aplikacyjnego niż dokładanie RAM-u.

Jeżeli cache jest duży, swap praktycznie nieużywany, a system działa sprawnie – „pełny RAM” jest w tym scenariuszu zjawiskiem korzystnym, nie problemem.

Kiedy prosty zestaw iostat + vmstat + sar już nie wystarcza?

Standardowe narzędzia są świetne do złapania 80–90% typowych problemów. Zaczynają być za mało szczegółowe, gdy:

• aplikacja jest skomplikowana i wiesz tylko, że „coś” blokuje I/O, ale nie wiesz, który komponent,
• problem dotyczy krótkich, rzadkich „pików”, trudnych do złapania w 1-sekundowych próbkach,
• potrzebujesz pełnych trace’y system calls, flamegraphów CPU, szczegółowych statystyk konkretnej bazy danych.

Wtedy wchodzą narzędzia typu APM, bpftrace, perf czy dedykowane profile dla baz danych. Zwykle jednak sensownie jest najpierw udowodnić na iostat/vmstat/sar, że problem faktycznie istnieje i w jakiej warstwie, a dopiero potem inwestować w cięższe rozwiązania.

Czy da się diagnozować I/O na serwerze bez instalowania dodatkowych agentów?

Tak, w większości przypadków wystarczą narzędzia dostępne w standardowych repozytoriach: pakiet sysstat (iostat, sar) oraz vmstat z procps/procps-ng. W wielu dystrybucjach są już zainstalowane lub dochodzą jednym lekkim poleceniem instalacji.

Praktyczny schemat „bez agentów” wygląda tak:

• vmstat 1–5 sekund w trakcie incydentu, żeby zobaczyć presję na pamięć i I/O,
• iostat -x 1 dla najbardziej obciążonych urządzeń,
• sar (jeśli włączony) do przejrzenia historii z ostatnich godzin/dni,
• prosta korelacja czasowa z logami aplikacji/bazy.

Taki zestaw jest lekki dla systemu, nie wymaga budżetu na licencje, a daje wystarczająco danych, by podjąć pierwsze decyzje: tuningi, zmiana harmonogramu zadań, dopiero w ostateczności rozbudowa storage’u.