Przejdź do treści 
Pokazuję krok po kroku, w jaki sposób analiza oczekiwania I/O za pomocą iostat i vmstat uwidacznia wąskie gardła i które metryki serwera Linux liczą się dla szybkich czasów odpowiedzi. W ten sposób ustalam jasne progi, interpretuję typowe wzorce i sugeruję konkretne środki optymalizacji. I/O oraz CPU w.
Punkty centralne
- iostat oraz vmstat zapewniają komplementarny widok obciążenia procesora i pamięci masowej.
- wa przez 15-20% i %utile przez 80% wykazują wąskie gardło we/wy.
- czekać oraz avgqu-sz wyjaśnić opóźnienia i kolejki.
- mpstat wykrywa nierównomiernie rozłożone obciążenie na rdzenie procesora.
- Strojenie waha się od MySQL do parametrów jądra i pamięci masowej.
Co oznacza I/O Wait na serwerach Linux?
W trybie oczekiwania I/O procesor czeka bezczynnie, ponieważ oczekuje na wolniejszą pamięć lub urządzenia sieciowe, co jest znane jako wa-w narzędziach takich jak top czy vmstat. Oceniam ten odsetek jako czas, w którym wątki blokują się, a żądania są wykonywane później, co użytkownicy bezpośrednio odczuwają jako spowolnienie. Wartości powyżej 10-20% często wskazują na w pełni wykorzystany serwer. Przechowywanie-Podsystem, na przykład gdy dyski twarde, macierze RAID lub serwery NFS są wykorzystywane do granic możliwości. W konfiguracjach hostingowych z bazami danych, niezindeksowane zapytania i szczyty zapisu powodują niepotrzebne czasy oczekiwania na dysku. Dysk. Jeśli chcesz odświeżyć te pojęcia, możesz znaleźć podstawy na stronie Zrozumienie oczekiwania na operacje wejścia/wyjścia, zanim pójdę na trening.
Szybki start: poprawne odczytywanie vmstat
Za pomocą vmstat mogę sprawdzić najważniejsze z nich Linux-i rozpoznać początkowe wzorce bez większego wysiłku. Wywołanie vmstat 1 10 zapewnia dziesięć migawek, w których zwracam szczególną uwagę na kolumny wa (I/O wait), bi/bo (block I/O) i si/so (swap). Dla mnie wysokie wartości bo przy jednoczesnym wzroście wa wskazują na wiele blokujących dostępów do zapisu, co często wskazuje na limity bufora lub wolne nośniki. Jeśli si/so pozostaje na poziomie zera, ale wa znacznie wzrasta, podejrzewam, że jest to czysty błąd. Przechowywanie-limit. W hostach wielordzeniowych łączę vmstat z mpstat -P ALL 1, ponieważ oczekiwanie na I/O często wpływa tylko na pojedyncze rdzenie i dlatego wydaje się bardziej nieszkodliwe niż jest w rzeczywistości.
Obraz procesora: us/sy/st, kolejka uruchamiania i przełączanie kontekstu
Z vmstat i mpstat odczytuję więcej niż tylko waWysoki my"Ciężkie" obliczeniowo aplikacje zostały przedstawione w kolejnych sekcjach, sy wskazuje na pracę jądra/sterownika, na przykład z intensywnymi I/O. W środowiskach zwirtualizowanych zwracam uwagę na st (Steal): Wysokie wartości st oznaczają, że maszyna wirtualna traci czas procesora, co sztucznie zawyża opóźnienia przy identycznym wzorcu I/O. Porównuję również kolejkę uruchamiania (r w vmstat) z liczbą procesorów: Stale wyższe r niż liczba procesorów wskazuje na przeciążenie procesora, a nie na Przechowywanie. Wiele zmian kontekstu (cs) w połączeniu z małymi synchronicznymi zapisami są wskaźnikiem gadatliwych wzorców I/O. W ten sposób unikam błędnego interpretowania braku procesora jako problemu I/O.
Dogłębne zrozumienie iostat: ważne metryki
iostat -x 1 daje mi rozszerzenie Dysk-metryki, które jasno opisują opóźnienia, wykorzystanie i kolejki. Rozpoczynam pomiary dla szczytów obciążenia i koreluję %util, await, svctm i avgqu-sz, aby rozróżnić przyczynę i skutek. Jeśli %util wzrośnie do 90-100%, a await i avgqu-sz również wzrosną, widzę nasycenie Płyta lub ograniczony wolumen. Jeśli await pokazuje wysokie wartości przy umiarkowanym %util, sprawdzam, czy nie ma zakłóceń spowodowanych buforowaniem, limitami kontrolera lub pojedynczymi dużymi żądaniami. r/s i w/s wprowadzają częstotliwość do obrazu, podczas gdy MB_read i MB_wrtn wyjaśniają objętość, co zapewnia mi ważne wartości porównawcze dla dedykowanych konfiguracji SSD i NVMe.
NVMe, SATA i RAID: co oznaczają %util, oczekiwanie i głębokość kolejki
Dokonuję ścisłego rozróżnienia między typami mediów: HDD pokazać wyższy czekać-wartości nawet przy umiarkowanej wskazówce, ponieważ dominują ruchy głowy. SSD/NVMe dobrze skaluje się z równoległością, dlatego wyższa wartość avgqu-sz może być normalne, o ile czekać pozostaje w granicach limitów. W przypadku NVMe z wieloma kolejkami zgłoszeń/zakończeń, odczytuję %util bardziej ostrożnie: poszczególne urządzenia mogą być już na limicie przy 60-70%, jeśli aplikacja nie generuje wystarczającej równoległości lub głębokości kolejki (nr_zapytania, queue_depth) jest zbyt mała. W RAID Sprawdzam, czy rozproszone losowe wejścia/wyjścia napotykają zbyt małe rozmiary pasków; następnie czekać oraz %utile nierównomiernie na dyskach członkowskich. Dlatego patrzę na iostat na urządzenie członkowskie, a nie tylko na wolumin kompozytowy, aby uwidocznić hotspoty. W przypadku warstw o strukturze dziennika (np. kopiowanie przy zapisie) spodziewam się nieco wyższych opóźnień zapisu, ale kompensuję to powiększonymi oknami zapisu zwrotnego lub wsadowaniem po stronie aplikacji.
Diagnostyczny przepływ pracy w przypadku długiego czasu oczekiwania
Każdą analizę rozpoczynam równolegle z vmstat 1 i iostat -x 1, dzięki czemu mogę synchronicznie zobaczyć stany procesora i status urządzenia oraz przypisać je do czasu. Następnie używam mpstat -P ALL 1, aby sprawdzić, czy poszczególne rdzenie działają wyjątkowo wysoko. wa co zapobiega nieprawidłowej interpretacji wartości średnich. Jeśli istnieją oznaki przyczyny, używam pidstat -d lub iotop, aby zobaczyć dokładnie, który PID używa najwięcej udziałów I/O. W środowiskach hostingowych z bazami danych najpierw rozróżniam między szczytami odczytu i zapisu, ponieważ strategie zapisu zwrotnego i wzorce fsync generują bardzo różne objawy i dlatego mogą być wykorzystywane do ukierunkowanych działań. Środki sprawiają, że jest to możliwe. W przypadku bardziej szczegółowych pytań dotyczących pamięci masowej, przegląd taki jak ten na stronie Wąskie gardło we/wy w hostingu, zanim zmodyfikuję jądro lub system plików.
Wyraźne rozgraniczenie między wirtualizacją a kontenerami
W maszynach wirtualnych rozważam wa wraz z st (Steal) i dodatkowo mierzyć na hypervisorze, ponieważ tylko tam prawdziwe urządzenia i Wskazówki są widoczne. Agregacje pamięci masowej (thin provisioning, deduplikacja, migawki) przenoszą szczyty opóźnień w dół stosu - w maszynie wirtualnej ma to następujący efekt czekać skacze, podczas gdy %util pozostaje niepozorny. W kontenerach ograniczam lub odłączam I/O z regułami Cgroup (np. limitami IOPS/przepustowości) w celu Hałaśliwi sąsiedzi aby je okiełznać. Dokumentuję limity dla każdej usługi, dzięki czemu zmierzone wartości są powtarzalne, a alarmy zachowują swój kontekst. Ważne: Wysoki wa w maszynie wirtualnej mogą być wyzwalane przez kopie zapasowe, czyszczenie lub przebudowę całego hosta - koreluję czasy z zadaniami hosta przed dotknięciem aplikacji.
Limity, progi i kolejne kroki
Używam kilku jasnych progów, aby zdecydować, czy istnieje prawdziwe wąskie gardło i jakie działania należy podjąć, aby zauważalnie ustabilizować wydajność. Biorę pod uwagę rodzaj nośnika, obciążenie i wymagania dotyczące opóźnień, ponieważ te same liczby na HDD i NVMe mają różne implikacje. Używam poniższej tabeli jako szybkiego przewodnika, którego używam w moich playbookach. Dokonuję pomiarów kilka razy w ciągu minut i pod obciążeniem, aby wartości odstające nie generowały fałszywych alarmów i abym mógł rozpoznać trendy. Używam tego jako podstawy do ukierunkowanych działań zamiast odruchowej wymiany sprzętu lub Parametry masowo.
| Metryki | Próg | Interpretacja | Następne kroki |
|---|---|---|---|
| wa (vmstat) | > 15-20% | Znaczny czas oczekiwania na wejście/wyjście | Sprawdź iostat; znajdź przyczynę za pomocą pidstat/iotop; przeanalizuj buforowanie i zapisy |
| %utile (iostat) | > 80-90% | Wykorzystywane urządzenie | korelacja await/avgqu-sz; sprawdzenie głębokości kolejki, harmonogramu, RAID i SSD/NVMe |
| czekać (ms) | > 10-20 ms SSD, > 30-50 ms HDD | Zwiększone opóźnienie | Rozróżnianie między losowym a sekwencyjnym; dostosowywanie opcji systemu plików, zapisu zwrotnego, dziennika |
| avgqu-sz | > 1-2 trwałe | Kolejka rośnie | Ograniczenie/zwiększenie równoległości; optymalizacja wzorca I/O aplikacji; sprawdzenie limitów kontrolera |
| si/so (vmstat) | > 0 pod obciążeniem | Wąskie gardło pamięci masowej | Zwiększenie pamięci RAM; dostrojenie zapytań/bufora podręcznego; sprawdzenie limitów wymiany/pamięci |
Przyczyny w stosie: DB, system plików, wirtualizacja
W przypadku baz danych często spotykam się z nieindeksowanymi złączeniami, zbyt małymi buforami i nadmiernymi wywołaniami fsync. Przyczyny dla wysokich wartości oczekiwania. Sprawdzam plany zapytań, aktywuję dzienniki dla powolnych instrukcji i obiektywnie dostosowuję rozmiary, takie jak pula buforów InnoDB, rozmiary plików dziennika i otwartych plików. Na poziomie systemu plików sprawdzam opcje montowania, tryby dziennika i wyrównanie do paska RAID, ponieważ niewłaściwe kombinacje powodują eksplozję czasów oczekiwania. W konfiguracjach zwirtualizowanych nie polegam na pomiarach w samej maszynie wirtualnej, ale patrzę na hosta, ponieważ to tam znajdują się rzeczywiste urządzenia blokowe i pliki. Wskazówki stają się widoczne. Pozwala mi to wyraźnie oddzielić efekty deduplikacji, thin provisioningu lub sąsiadujących maszyn wirtualnych od wzorców aplikacji.
System plików i opcje montowania w szczegółach
Oceniam systemy plików w świetle obciążenia pracą: ext4 w trybie uporządkowanym lub zapisu zwrotnego minimalizuje bariery dla intensywności zapisu, podczas gdy XFS dzięki projektowi dziennika dla równoległych obciążeń. Opcje takie jak noatime lub relatime ograniczenie zapisu metadanych, czas leniuchowania przenosi aktualizacje znaczników czasu do zapisu zwrotnego w pakietach. W przypadku journalingu sprawdzam interwały commitów (np. commit=) i sprawdzam, czy wymuszone płukania (bariery) nie są zaostrzane przez polityki pamięci podręcznej kontrolera. W RAID zwracam uwagę na czyste wyrównanie do paska (Parted/FDISK z początkiem 1MiB), w przeciwnym razie czekać poprzez Read-Modify-Write nawet w przypadku rzekomo sekwencyjnych wzorców. W przypadku baz danych często używam strategii O_DIRECT lub bezpośredniego płukania dziennika - ale tylko po pomiarze, ponieważ pamięć podręczna systemu plików może znacznie zmniejszyć obciążenie odczytu, jeśli zestaw roboczy mieści się w niej.
Tuning: od jądra do aplikacji
Zaczynam od prostych zwycięstw, na przykład indeksowania zapytań, zapisu wsadowego i rozsądnej konfiguracji puli połączeń, zanim zacznę od poziomu systemu. W przypadku zapisu zwrotnego dostosowuję vm.dirty_background_ratio, vm.dirty_ratio i vm.dirty_expire_centisecs w kontrolowany sposób, aby system zapisywał w sposób ciągły i generował mniej blokad bez zapychania pamięci. W przypadku urządzeń blokowych sprawdzam harmonogram I/O, głębokość kolejki i wyprzedzenie odczytu, ponieważ parametry te bezpośrednio kształtują opóźnienia i przepustowość. W przypadku kontrolerów RAID dostrajam rozmiar paska i politykę pamięci podręcznej, natomiast w przypadku SSD/NVMe dla firmware, TRIM i spójnych ustawień overprovisioningu. Po każdej zmianie sprawdzam za pomocą vmstat i iostat przez kilka minut, czy oczekiwanie spada, a %util pozostaje stabilny, zanim wykonam następny krok.
Przerwania, NUMA i powiązania
Monitoruję obciążenie IRQ i topologię NUMA, ponieważ oba te czynniki mają zauważalny wpływ na opóźnienia. NVMe-Wiążę przerwania z procesorami domeny NUMA kontrolera poprzez powinowactwo, dzięki czemu ścieżki danych pozostają krótkie. Jeśli burza IRQ jest uruchomiona na rdzeniu, widzę wysokie sy a reszta procesorów wydaje się być bezczynna; mpstat ujawnia to. Zezwalam na irqbalance tylko wtedy, gdy dystrybucja pasuje do sprzętu - w przeciwnym razie ustawiam określone powinowactwa. Sprawdzam również, czy aplikacja i jej I/O działają w tej samej strefie NUMA (lokalizacji pamięci masowej), ponieważ dostępy między gniazdami powodują czasy oczekiwania w czekać można zamaskować.
Automatyzacja i wizualizacja pomiarów
Aby mieć pewność, że rozpoznaję trendy, automatyzuję pomiary i integruję iostat/vmstat z narzędziami monitorującymi, które mogą wyświetlać dane historyczne. Dane save. Alarmy ustawiam zachowawczo, na przykład od wa > 15% w kilku odstępach czasu, w połączeniu z progami dla await i %util, aby uniknąć fałszywych alarmów. W przypadku ogólnych ekranów metryk używam pulpitów nawigacyjnych, które zestawiają metryki procesora, pamięci masowej, sieci i aplikacji, dzięki czemu korelacje są natychmiast widoczne. Jeśli potrzebujesz wprowadzenia do metryk, możesz je znaleźć na stronie Metryki serwera kompaktowy kontekst dla codziennej pracy. Ważny jest dla mnie powtarzalny proces: pomiar, sformułowanie hipotezy, wprowadzenie korekty, ponowny pomiar i analiza wyników. Wyniki dokument.
Powtarzalne testy obciążeniowe z fio
Jeśli brakuje mi rzeczywistego obciążenia lub chcę zweryfikować hipotezy, używam krótkotrwałych fio-testy. Symuluję reprezentatywne wzorce (np. 4k losowego odczytu, 64k sekwencyjnego zapisu, mieszane profile 70/30) i zmieniam je. iodepth, aby ustawić okno sweet spot pomiędzy czekać i przepustowość. Ściśle oddzielam ścieżki testowe od danych produkcyjnych i odnotowuję warunki brzegowe (system plików, opcje montowania, scheduler, głębokość kolejki), dzięki czemu mogę prawidłowo kategoryzować wyniki. Po dostrojeniu, te same testy są używane jako kontrola regresji; tylko wtedy, gdy czekać oraz %utile konsekwentnie wyglądają lepiej, wprowadzam zmiany na powierzchni.
Rozpoznawanie wzorców błędów: typowe wzorce
Jeśli obserwuję wysokie wa przy jednocześnie wysokim %utile i rosnącym avgqu-sz, wszystko przemawia za nasyceniem na Urządzenie, tj. rzeczywiste limity fizyczne. Wysokie wartości oczekiwania przy umiarkowanym %util wskazują na osobliwości kontrolera lub pamięci podręcznej, takie jak bariery, zapis przez lub sporadyczne płukanie. Rosnące wartości si/so wraz ze spadkami w pamięci podręcznej wyraźnie wskazują na brak pamięci RAM, co sztucznie zawyża I/O i wydłuża czas oczekiwania. Jeśli dysk pozostaje niepozorny, ale aplikacja tworzy duże, wymagające synchronizacji zapisy, przenoszę pracę na zapis asynchroniczny, pipelining lub Partia-mechanizmy. W konfiguracjach NFS lub sieciowej pamięci masowej sprawdzam również opóźnienia, MTU, retransmisje i buforowanie po stronie serwera, ponieważ czas sieci jest tutaj bezpośrednio maskowany jako opóźnienie we / wy.
NFS/iSCSI i rozproszona pamięć masowa
Na stronie NFS i iSCSI, rozróżniam urządzenie i ścieżkę sieciową: iostat pokazuje tylko to, co widzi warstwa blokowa - rozpoznaję również retransmisje, opóźnienia i problemy z oknami za pomocą metryk sieciowych. Wysoki czekać z umiarkowanym %utile na wirtualnym urządzeniu blokowym jest typowe, gdy sieć się zatrzymuje lub pamięć podręczna po stronie serwera się ochładza. W przypadku NFS sprawdzam opcje montowania (rsize/wsize, proto, sync/async) i po stronie serwera (wątki, zasady eksportu, cache), w przypadku iSCSI parametry sesji i kolejki. Planuję okna konserwacji dla zadań serwerowych (scrubs, rebuilds, rebalancing), aby nie nasyciły współdzielonej pamięci masowej w godzinach szczytu, a tym samym spowodowały niedostępność serwera. wa na wszystkich klientach.
Praktyczne przykłady: trzy krótkie scenariusze
Klaster blogowy z poradami dotyczącymi pisania
W najlepszym czasie komentarze i cache invalidate rosną, po czym await i avgqu-sz w iostat znacznie rosną, podczas gdy %util trzyma się 95%. Delikatnie zwiększam parametry zapisu zwrotnego, optymalizuję unieważnianie pamięci podręcznej na poziomie ścieżki i zwiększam bufor dziennika InnoDB, aby było mniej małych zapisów synchronizacji. Po tym, await spada mierzalnie, wartości bo pozostają wysokie, ale wa spada, co natychmiast skraca czas odpowiedzi. Jednocześnie zastępuję poszczególne dyski twarde dyskami SSD dla dziennika, co dodatkowo odciąża wąskie gardło. Wzorzec pokazuje, jak Partia-Połączenie pisania i szybszego prowadzenia dziennika.
Sklep ze szczytami odczytu i indeksami wyszukiwania
Promocje generują duże obciążenie odczytu, r/s wzrasta, oczekiwanie pozostaje umiarkowane, ale aplikacja nadal wolno reaguje na nawigację po filtrach. Rozpoznaję wiele niebuforowanych zapytań bez odpowiednich indeksów, które przekraczają zestaw roboczy pamięci podręcznej systemu plików. Dzięki ukierunkowanemu indeksowaniu i przepisywaniu zapytań, r/s spada, trafienia są częściej w pamięci podręcznej, a iostat potwierdza niższy MB_read przy tej samej przepustowości. Jednocześnie nieznacznie zwiększam read-ahead, aby wydajniej obsługiwać sekwencyjne skanowanie, co dodatkowo zmniejsza opóźnienia. W ten sposób sprawdzam, czy Czytaj-wzorce prowadzą do ponownych trafień pamięci podręcznej.
Host maszyny wirtualnej z „hałaśliwym sąsiadem“
W poszczególnych maszynach wirtualnych top pokazuje wysoki wa, ale iostat w maszynie wirtualnej widzi tylko urządzenia wirtualne z mylącym wykorzystaniem. Dokonuję również pomiarów w hiperwizorze, widzę nasycone rzeczywiste urządzenia blokowe i identyfikuję sąsiednią maszynę wirtualną z agresywnymi kopiami zapasowymi jako przyczyną. Limity przepustowości i zmodyfikowane okna kopii zapasowych stabilizują oczekiwanie i %util na całym hoście. Następnie ponownie wykonuję pomiary w maszynie wirtualnej i na hoście, aby potwierdzić i zapobiec efektowi po obu stronach. Potwierdza to, że rzeczywiste Urządzenia-metryki zawsze pokazują prawdę u hosta.
Lista kontrolna dla następnego incydentu
Najpierw uruchamiam dzienniki i pomiary, aby nie utracić żadnych sygnałów, i utrzymuję vmstat 1 i iostat -x 1 uruchomione przez kilka minut. Następnie koreluję szczyty czasowe ze zdarzeniami aplikacji i zegarami systemowymi, po czym ustalam poszczególne procesy za pomocą pidstat -d i formułuję hipotezy. Następnym krokiem jest sprawdzenie trafień pamięci, swapu i cache, aby niedobory pamięci RAM nie zostały błędnie rozpoznane jako Dysk-pojawia się problem. Dopiero po wyizolowaniu przyczyny zmieniam dokładnie jedną rzecz, rejestruję ustawienia i oceniam wpływ na await, %util i wa. W ten sposób utrzymuję powtarzalność analizy, uczę się z każdego incydentu i skracam czas do Rozwiązanie wyraźnie.
Częste błędne interpretacje i przeszkody
Nie daję się zwieść pojedynczym szczytom: Pojedyncze sekundy z wysokimi wa są normalne, tylko utrzymujące się płaskowyże wskazują na strukturalne wąskie gardło. %utile blisko 100% jest krytyczna tylko wtedy, gdy czekać w tym samym czasie - w przeciwnym razie urządzenie jest po prostu zajęte. Wł. SSD/NVMe jest wyższym avgqu-sz Często jest to celowe, aby wykorzystać wewnętrzną równoległość; dławię tylko wtedy, gdy nie są osiągane docelowe opóźnienia. Sprawdzam skalowanie częstotliwości procesora: Agresywne oszczędzanie energii może wydłużyć czas reakcji i tak dalej. wa wydają się pogarszać. I oddzielam TTFB aplikacji od opóźnienia pamięci masowej - sieć, uściski dłoni TLS i usługi upstream mogą powodować podobne objawy bez iostat „jest “winny".
Krótkie podsumowanie dla administratorów
Analiza I/O wait za pomocą iostat i vmstat działa szybko, jeśli odczytuję wa, await, %util i avgqu-sz razem i odnoszę je do kontekstu obciążenia. Najpierw identyfikuję, czy występuje rzeczywiste nasycenie urządzenia, czy też wzorce pamięci i aplikacji powodują opóźnienia, a następnie wybieram odpowiednią dźwignię. Niewielkie, ukierunkowane korekty zapytań, parametrów zapisu zwrotnego, harmonogramów lub głębokości kolejek często mają największy wpływ, zanim konieczne będą kosztowne zmiany sprzętowe. Pomiar, hipoteza, zmiana i ponowny pomiar pozostają moją stałą sekwencją, dzięki czemu decyzje pozostają zrozumiałe i powtarzalne. W ten sposób utrzymuję Linux-Serwer jest responsywny i zapewnia zauważalnie lepsze wyniki Czasy reakcji pod obciążeniem.
