Mam stałe oczekiwanie na operacje we / wy około 50%, ale po uruchomieniu iostat 1pokazuje niewiele lub brak aktywności na dysku.

Co powoduje oczekiwanie bez Iopsa?

UWAGA: Nie ma tutaj systemów plików NFS ani FUSE, ale korzysta z wirtualizacji Xen.

NFS może to zrobić i nie zaskoczyłoby mnie, gdyby inne sieciowe systemy plików (a nawet urządzenia oparte na FUSE) miały podobne efekty.

Czy jest szansa, że ​​inne maszyny wirtualne na serwerze niszczą dysk?

Wiem z wirtualizacji, że możesz uzyskać dziwne wyniki, jeśli węzeł hosta jest przeciążony.

Jeśli jest to środowisko Amazon EC2 Xen korzystające z pamięci masowej opartej na instancjach, poproś Amazon o sprawdzenie stanu hosta zawierającego ten obraz.

Jeśli jest to środowisko Xen, w którym można uzyskać dostęp do hiperwizora, sprawdź IOwait z zewnątrz dla obrazu dysku (pliku, sieci, wycinka LVM itp.) Używanego dla urządzeń xvda i xvdb. Będziesz także chciał sprawdzić system We / Wy, ogólnie dla hiperwizora, ponieważ inne urządzenia dyskowe mogą monopolizować zasoby systemu.

iostat -txk 5

jest zwykle dobrym początkowym narzędziem diagnostycznym. Pobiera 5-sekundowe podsumowania We / Wy dla WSZYSTKICH dostępnych dla niego urządzeń, a zatem jest użyteczne zarówno dla obrazu VM, jak i dla niego.

Sprawdź dostępne deskryptory / i-węzły plików. Kiedy osiągniesz limit, zamieniają się i naśladują iowait

Edytować

Widziałem, że używasz xen, spójrz na swoje obecne przerwania, może się okazać, że blkif jest wyższy niż normalnie.

Trochę późno, ale zainstaluj munin, a to naprawdę pomoże w przyszłym debugowaniu.

sudo sysctl vm.block_dump=1

Następnie sprawdź dmesg, aby zobaczyć, co wykonuje operacje odczytu / zapisu bloków lub brudzenia i-węzłów.

Sprawdź także limit nofile w limit.conf, proces może żądać więcej plików, niż jest dozwolone.

OSTRZEŻENIE: HDPARM JEST NIEBEZPIECZNY, ZAWSZE PRZECZYTAJ KOMENDĘ, KTÓREJ KORZYSTASZ!

Jeśli żadne inne maszyny wirtualne nie obciążają dysków twardych, zrób to

hdparm -f

na podstawowych dyskach fizycznych. Być może pamięć podręczna dysku nie działa dokładnie. Spowoduje to opróżnienie danych przechowywanych w pamięci podręcznej i możesz stale monitorować operacje we / wy, czy ma zamiar wzrosnąć ponownie po opróżnieniu. Jeśli tak, będzie to problem z pamięcią podręczną.

Przy średnim obciążeniu widziałem wzrost liczby zablokowanych operacji sieciowych (tj. Długie połączenia z zewnętrznym serwerem DB). Nie wiem na pewno, ale zgaduję, że sieciowe IO może spowodować, że procesor zacznie działać? Czy ktoś może potwierdzić?

Mogą to być urządzenia sprzężone zwrotnie, które same są montowane w sieci.

Na moich maszynach NFS jest największym „producentem” IO-WAIT. W moim laptopie mam dysk SSD, który jest szybki jak diabli, więc „prawdziwe IO” nie stanowi problemu. Niemniej jednak czasami mam dużo zamówień IO z powodu moich zamontowanych akcji NFS.

SCP czasami wydaje się również prowadzić do IO Wait, ale w znacznie mniejszym stopniu.

To może być cokolwiek. Oznacza to po prostu, że coś czeka na zakończenie operacji we / wy. Możesz dowiedzieć się, jaki to proces za pomocą ps, a następnie dołączyć do niego gdb i sprawdzić ślad, aby ustalić, które połączenie jest zawieszone (zwykle są to pewne rzeczy związane z siecią lub nagle odłączony dysk). Aby uzyskać informacje o fd, sprawdź / proc.

Doświadczyłem również podobnego problemu tuż przed awarią dysku w macierzy RAID, a niektóre kable SATA z ciasnymi zagięciami zaczęły zawodzić.

Zużycie procesora było bliskie 0%, ale 1 lub więcej procesorów w systemie 4-rdzeniowym spędzało 100% swojego czasu w IOwait przez dłuższy czas (znaleziony przez topwielowierszowy wyświetlacz procesora) z bardzo niskim IOps i przepustowością (znaleziono via iostat), ale pękająca wysoka aktywność przerywania. Interaktywne korzystanie z wiersza poleceń było bolesne podczas dowolnego dostępu do dysku (tj. Automatycznego zapisywania z czyjejś emacssesji), ale poza tym było tolerowane, gdy minęły okresy IOwait (i prawdopodobnie operacje zakończyły się powodzeniem po wielu próbach).