O ile czytałem o iowait, wciąż jest dla mnie tajemnicą.

Wiem, że jest to czas spędzony przez procesor na oczekiwaniu na zakończenie operacji IO, ale jakie dokładnie operacje IO? Nie jestem również pewien, dlaczego to takie ważne? Czy procesor nie może po prostu zrobić czegoś innego po zakończeniu operacji we / wy, a następnie wrócić do przetwarzania danych?

Jakie są odpowiednie narzędzia do diagnozowania, które procesy dokładnie czekały na IO.

A jakie są sposoby na zminimalizowanie czasu oczekiwania IO?

Wiem, że jest to czas spędzony przez procesor na oczekiwaniu na zakończenie operacji IO, ale jakie dokładnie operacje IO? Nie jestem również pewien, dlaczego to takie ważne? Czy procesor nie może po prostu zrobić czegoś innego po zakończeniu operacji we / wy, a następnie wrócić do przetwarzania danych?

Tak, system operacyjny zaplanuje uruchomienie innych procesów, podczas gdy jeden będzie zablokowany na IO. Jednak w tym procesie, chyba że korzysta z asynchronicznego We / Wy, nie będzie postępować do momentu zakończenia dowolnej operacji We / Wy.

Jakie są odpowiednie narzędzia do diagnozowania, które procesy dokładnie czekały na IO.

Niektóre narzędzia, które mogą okazać się przydatne

• iostat, aby monitorować czasy obsługi dysków
• iotop (jeśli jądro to obsługuje), aby monitorować rozkład żądań We / Wy na proces
• strace, aby zobaczyć rzeczywiste operacje wydane przez proces

A jakie są sposoby na zminimalizowanie czasu oczekiwania IO?

• upewnij się, że masz wolną pamięć fizyczną, aby system operacyjny mógł buforować bloki dysku w pamięci
• utrzymuj użycie dysku systemu plików poniżej 80%, aby uniknąć nadmiernej fragmentacji
• dostrój swój system plików
• użyj kontrolera macierzy zasilanego bateryjnie
• wybierz dobre rozmiary buforów podczas wykonywania operacji io

Stare pytanie, ostatnio zderzone, ale uważało, że istniejące odpowiedzi są niewystarczające.

IOWait definicja i właściwości

IOWait (zwykle oznaczony %wau góry) to podkategoria bezczynności ( %idlejest zwykle wyrażana jako wszystkie bezczynności z wyjątkiem zdefiniowanych podkategorii), co oznacza, że ​​procesor nic nie robi. Dlatego dopóki procesor może przetwarzać inny proces, będzie to robił. Ponadto bezczynność, użytkownik, system, iowait itp. Są miarą w odniesieniu do procesora. Innymi słowy, możesz myśleć o iowait jako bezczynności spowodowanej oczekiwaniem na io.

Iowait to czas poświęcony na odbieranie i obsługę przerwań sprzętowych jako procent tików procesora. Przerwania programowe zwykle są oznaczone osobno jako %si.

Znaczenie i potencjalne nieporozumienia

IOWait jest ważny, ponieważ często jest kluczową miarą, aby wiedzieć, czy masz wąskie gardło w IO. Ale brak iowait niekoniecznie oznacza, że ​​twoja aplikacja nie jest wąska dla IO. Rozważ dwie aplikacje działające w systemie. Jeśli program 1 jest mocno wąski, a program 2 jest dużym obciążeniem procesora, %user + %systemprocesor może nadal być około ~ 100% i odpowiednio, iowait pokaże 0. Ale to tylko dlatego, że program 2 jest intensywny i względnie wydaje się, że nie mówi nic o program 1, ponieważ wszystko to jest z punktu widzenia procesora.

Narzędzia do wykrywania IOWait

Zobacz posty Dave'a Cheneya i Xerxesa

Ale również prosta toppokaże się %wa.

Zmniejszenie IOWait

Ponadto, ponieważ już prawie wkraczamy w 2013 r., Oprócz tego, co powiedzieli inni, opcja po prostu niesamowitych urządzeń pamięci masowej we / wy są przystępne, a mianowicie dyski SSD. Dyski SSD są niesamowite !!!

iowait

iowaitoznacza czas, przez który procesor / procesory czekają (tj. są w stanie bezczynności i nic nie robią ), podczas którego faktycznie występowały zaległe żądania We / Wy dysku.

Zazwyczaj oznacza to, że urządzenia blokowe (tj. Dyski fizyczne, a nie pamięć) są zbyt wolne lub po prostu nasycone.

W związku z tym należy zauważyć, że jeśli widzisz wysoką średnią obciążenia w systemie, a po inspekcji zauważysz, że większość z nich jest spowodowana oczekiwaniem we / wy, niekoniecznie oznacza to, że twój system ma kłopoty - i dzieje się tak, gdy twój maszyna po prostu nie ma nic do roboty poza procesami związanymi z We / Wy (tj. procesami, które wykonują więcej operacji We / Wy niż cokolwiek innego (wywołania systemowe niezwiązane z We / Wy)). Powinno to również wynikać z faktu, że wszystko, co robisz w systemie, nadal bardzo szybko reaguje.

przybory

• sar(z sysstatpakietu, dostępny na większości * nix maszyn)
• iostat
• sarface(front-end do sar)

Uważam, że wyjaśnienia i przykłady z tego linku są bardzo przydatne: Czym dokładnie jest „iowait”? . BTW, ze względu na kompletność, we / wy odnosi się tutaj do We / Wy dysku, ale może również obejmować We / Wy na dysku zamontowanym w sieci (takim jak NFS), jak wyjaśniono w tym innym poście .

Zacytuję kilka ważnych części (na wypadek, gdyby link przestał istnieć), niektóre z nich byłyby powtórzeniami tego, co już powiedzieli inni, ale przynajmniej dla mnie były one wyraźniejsze:

Podsumowując w jednym zdaniu, „iowait” oznacza procent czasu bezczynności procesora ORAZ co najmniej jednego wejścia / wyjścia w toku.

Każdy procesor może znajdować się w jednym z czterech stanów: user, sys, idle, iowait.

Zastanawiałem się, co się stanie, gdy system ma inne procesy gotowe do uruchomienia, podczas gdy jeden proces czeka na operacje we / wy. Poniżej to wyjaśnia:

Jeśli procesor jest bezczynny, jądro ustala, czy aktualnie trwa co najmniej jedno wejście / wyjście na dysku lokalnym lub dysku zdalnie zamontowanym (NFS), który został zainicjowany z tego procesora. Jeśli tak, to licznik „iowait” jest zwiększany o jeden. Jeśli nie ma żadnych operacji we / wy zainicjowanych z tego procesora, licznik „bezczynności” jest zwiększany o jeden.

A oto przykład:

Powiedzmy, że na procesorze działają dwa programy. Jednym z nich jest program „dd” odczytujący z dysku. Drugi to program, który nie wykonuje operacji wejścia / wyjścia, ale spędza 100% czasu na pracy obliczeniowej. Załóżmy teraz, że występuje problem z podsystemem we / wy i że fizyczne we / wy zajmują ponad sekundę. Za każdym razem, gdy program „dd” śpi podczas oczekiwania na zakończenie operacji we / wy, drugi program może działać na tym procesorze. Kiedy nastąpi przerwanie zegara, zawsze będzie działał program w trybie użytkownika lub w trybie systemowym. Dlatego wartości% bezczynności i% iowait będą wynosić 0. Nawet jeśli iowait ma teraz wartość 0, nie oznacza to, że NIE występuje problem we / wy, ponieważ oczywiście jest jeden, jeśli fizyczne we / wy zajmują sekundę.

Warto przeczytać cały tekst. Oto lustro tej strony na wypadek, gdyby się zawiodła.

W systemie Solaris używam DTrace, aby sprawdzić, co robią procesy, jeśli chcę zobaczyć, jakie operacje we / wy są uruchomione. W systemie Linux istnieje podobny program o nazwie systemtap, który zapewnia podobny poziom ekspozycji na jądro i wywołania procesów.

Jednym z przykładów, których użyłem podczas nauki DTrace, było porównanie cppolecenia z ddpoleceniem. Widać, że ddrobi o wiele więcej odczytów do zapisu, podczas gdy cpnie, głównie ze względu na dddomyślny rozmiar bufora (jeśli dobrze pamiętam).

Jakie operacje IO będą zależeć od twoich aplikacji i konfiguracji.

Jest to ważne, ponieważ w niektórych przypadkach procesor nie może uzyskać danych lub instrukcji, które musi kontynuować. W niektórych przypadkach może być kontynuowane, ale będzie zależeć od tego, jakie aplikacje działają, co może zrobić. Jeśli masz aplikację z jednym wątkiem, która ma duży dostęp do dysku, musisz poczekać.

Aby zminimalizować czas operacji we / wy, kupuj coraz więcej pamięci, zdobywaj szybsze dyski, defragmentuj posiadane dyski.

Jeśli jest to aplikacja wewnętrzna, która stanowi wąskie gardło, sprawdź, czy można ją zoptymalizować pod kątem odczytu w większych blokach lub wykonywania asysty synchronicznej we / wy.

użycie ps aux może wydrukować proces STAT,
jeśli stat jest D lub Ds, proces jest w trybie nieprzerwanego uśpienia (zwykle IO),
gdy proces wchodzi w nieprzerwany tryb uśpienia, dodaje się nr_iowait z kolejki, a jeśli nr_iowait> 0, liczony jest czas bezczynności procesora do iowait

vmstat pokazuje także liczbę bloków procesów
r: liczbę procesów oczekujących na czas wykonywania.
b: Liczba procesów w nieprzerwanym śnie.

http://bencane.com/2012/08/06/trou Rozwiązywanie problemów-high-io-wait-in-linux/