iostat i iotop: diagnozowanie wąskich gardeł pamięci masowej w systemie Linux

Kiedy serwer Linux działa wolno, jednym z pierwszych miejsc, na które należy zwrócić uwagę, jest pamięć masowa. iostat pokazuje, czy dysk jest przeciążony; iotop pokazuje, który proces powoduje obciążenie. Używane razem odpowiadają na dwa istotne pytania: czy dysk rzeczywiście jest wąskim gardłem, a jeśli tak, to co go obciąża? W tym poście omówiono instalację, sposób odczytywania wyników (w tym, gdzie w nowoczesnym sprzęcie znajduje się wskaźnik iostat %util znajduje się na nowoczesnym sprzęcie) oraz proces przechodzenia od objawu do rozwiązania.

Instalacja iostat i iotop

iostat jest dostarczany wraz z pakietem sysstat; iotop jest dostarczany osobno. Zainstaluj oba:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

W systemie Ubuntu pakiet sysstat jest domyślnie wyłączony. Aby zebrać dane w tle do późniejszej analizy za pomocą sar, edytuj /etc/default/sysstat, ustaw ENABLED="true"i uruchom ponownie usługę:

sudo systemctl restart sysstat

iotop musi działać jako root. W systemie RHEL 9 i nowszych rozliczanie opóźnień jest domyślnie wyłączone, co pozostawia IO i SWAPIN puste. Włącz je za pomocą:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Dodaj kernel.task_delayacct = 1 do /etc/sysctl.conf , aby zachować ustawienia po ponownym uruchomieniu systemu.

Odczyt wyników iostat

Uruchom iostat z rozszerzonymi statystykami i zignoruj pierwszą próbkę, która pokazuje tylko średnie od momentu uruchomienia systemu:

iostat -xz 2

Flaga -x dodaje rozszerzone statystyki, -z ukrywa urządzenia w stanie bezczynności, a 2 odświeża dane co dwie sekundy. Istotne kolumny:

• await: średni czas w milisekundach potrzebny do zrealizowania żądania wejścia/wyjścia, w tym czas oczekiwania w kolejce. Najważniejsza liczba, gdy użytkownicy skarżą się na spowolnienie.
• r/s oraz w/s: IOPS odczytu i zapisu. W połączeniu z rkB/s i wkB/s dane te wskazują, czy obciążenie jest losowe (wysokie IOPS, niska przepustowość), czy sekwencyjne (niskie IOPS, wysoka przepustowość).
• aqu-sz: średnia głębokość kolejki. W przypadku dysków HDD utrzymywanie wartości powyżej 1 oznacza, że dysk nie nadąża.
• %util: procent czasu, w którym urządzenie miało co najmniej jedną operację we/wy w toku. Przydatne w przypadku dysków HDD, mylące w przypadku NVMe (patrz poniżej).

Krótkie odniesienie do progów:

To, gdzie znajduje się %util

%util jest wskaźnikiem, po który większość ludzi sięga w pierwszej kolejności, a w przypadku NVMe jest on bardzo mylący. Jądro traktuje %util jako „dowolną operację wejścia/wyjścia w toku w dowolnym momencie”, co jest w porządku w przypadku dysku talerzowego, który przetwarza jedno żądanie na raz, ale nie ma znaczenia dla urządzeń NVMe, które obsługują tysiące żądań równolegle w kolejkach sprzętowych. Dysk NVMe może wykazywać 100% %util , działając przy 5% swojej rzeczywistej pojemności.

W przypadku NVMe nie należy ufać r_await, w_await, a aqu-sz zamiast tego. Jeśli r_await utrzymuje się poniżej 1 ms, a głębokość kolejki jest znacznie mniejsza od głębokości kolejki sprzętowej urządzenia (często 1024 lub więcej), dysk nie jest w rzeczywistości przeciążony, niezależnie od tego, co %util wskazuje.

Aby uzyskać szybki podgląd NVMe w MB/s zamiast kB/s:

iostat -xm 1

W przypadku długoterminowego gromadzenia danych można później skorelować je z logami aplikacji:

iostat -x -t 5 720 > /var/log/iostat.log

To pobiera próbki co 5 sekund przez godzinę. sar z tego samego pakietu sysstat dostarcza równoważnych danych z trwałym archiwum historycznym i jest lepszym wyborem do ciągłego monitorowania.

Potwierdzenie za pomocą CPU iowait

Jeśli iostat pokazuje obciążenie pamięci masowej, sprawdź to z kolumną %iowait w podsumowaniu CPU u góry tego samego wyniku. Utrzymujące się %iowait wartość powyżej 15–20% w połączeniu z wysokim await potwierdza, że wąskim gardłem jest pamięć masowa. Jeśli %iowait jest wysoka, ale await wygląda normalnie, uruchom vmstat 1 i sprawdź si i so . Aktywność wymiany różna od zera oznacza, że występuje ograniczenie pamięci, a ruch na dysku wynika z stronicowania, a nie z operacji wejścia/wyjścia aplikacji.

Analiza wyników iotop

Gdy iostat potwierdzi wąskie gardło pamięci masowej, iotop wskaże, który proces jest za to odpowiedzialny. Zacznij od:

sudo iotop -o

Flaga -o flaga ukrywa procesy bezczynne, pozostawiając tylko te, które aktywnie wykonują operacje wejścia/wyjścia. Kolumny, na które należy zwrócić uwagę:

• DISK READ / DISK WRITE: przepustowość w czasie rzeczywistym na proces. Wskazuje oczywistych „ciężkich graczy”.
• IO: procent czasu, w którym proces jest zablokowany na operacjach wejścia/wyjścia. Proces zapisujący z prędkością zaledwie 50 kB/s może wykazywać 99% IO, jeśli wykonuje drobne synchroniczne fsync() . Ta kolumna ma większe znaczenie niż sama przepustowość.
• SWAPIN: procent czasu oczekiwania na strony wymiany. Wartość niezerowa oznacza, że system stosuje stronicowanie, a „problem z pamięcią masową” jest w rzeczywistości problemem z pamięcią operacyjną.

W przypadku aplikacji wielowątkowych (MySQL, PostgreSQL, obciążenia Java) należy zagregować wątki z powrotem do procesów za pomocą -Pi dodaj -a , aby zgromadzić sumy od momentu uruchomienia iotop:

sudo iotop -oPa

Flaga -a jest sztuczką pozwalającą wychwycić obciążenia o charakterze impulsowym, takie jak zadania tworzenia kopii zapasowych, które działają tylko przez kilka sekund na raz i które w przeciwnym razie trudno byłoby dostrzec w widoku na żywo.

W przypadku nienadzorowanego logowania w nocy, kiedy nikt nie obserwuje systemu:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Spowoduje to zapisywanie nieinteraktywnej migawki co 10 sekund. Połącz to z sygnaturami czasowymi z zadań tworzenia kopii zapasowych lub cron, aby znaleźć sprawcę po fakcie.

Proces diagnostyczny

Większość analiz operacji wejścia/wyjścia na dysku przebiega według tego samego schematu:

1. iostat -xz 2 w celu potwierdzenia, że dysk faktycznie stanowi wąskie gardło. Sprawdź await, aqu-szi %iowait. Jeśli są one w normie, problem nie leży po stronie pamięci masowej i należy szukać przyczyny gdzie indziej.
2. iotop -oPa aby znaleźć proces generujący obciążenie. Zwróć większą uwagę na kolumnę IO niż na kolumnę przepustowości. Największymi winowajcami są często programy wykonujące wiele małych synchronicznych zapisów, a nie te, które przenoszą najwięcej bajtów.
3. lsof -p <pid> aby sprawdzić, z jakimi plikami ten proces ma do czynienia. Zazwyczaj pozwala to natychmiast zidentyfikować rodzaj obciążenia: dziennik zapisu z wyprzedzeniem bazy danych, plik dziennika aplikacji, punkt montowania kopii zapasowej, plik tymczasowy.

Dwa wzorce, o których warto wiedzieć.

Jeśli widzisz wątki jądra, takie jak jbd2/... (dziennik ext4) lub txg_sync (ZFS) na szczycie listy zapisujących w iotop, to reagują one na zapisy z innych procesów, a nie je inicjują. Proces w przestrzeni użytkownika generujący ruch dziennika jest rzeczywistą przyczyną; szukaj dalej.

Na serwerze VPS wysokie await przy niskim %util to klasyczny sygnał hałaśliwego sąsiada. Inny najemca monopolizuje współdzieloną pamięć masową, a Twoje operacje we/wy ustawiają się w kolejce po stronie hiperwizora, a nie na Twoim dysku wirtualnym. Możesz to potwierdzić, ale nie naprawić z poziomu systemu-gościa; rozwiązaniem jest albo zgłoszenie sprawy dostawcy, albo przeniesienie się na serwer z izolowaną pamięcią masową.

Naprawianie typowych wąskich gardeł we/wy

Gdy już wiesz, co obciąża dysk, rozwiązania są zazwyczaj proste.

Zmniejsz priorytet niekrytycznych operacji wejścia/wyjścia. ionice przenosi proces do klasy planowania bezczynności, gdzie wykorzystuje on przepustowość dysku tylko wtedy, gdy niczego innego nie potrzebuje:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

Pierwsza forma zmienia uruchomiony proces; druga uruchamia nowy, już w klasie bezczynności. W programie iotop można interaktywnie zmienić priorytet uruchomionego procesu, naciskając klawisz i.

Przenieś intensywne obciążenia do szybszej pamięci masowej. Jeśli iostat pokazuje, że dysk SATA jest przeciążony zapisami do bazy danych, a w tej samej obudowie znajduje się bezczynny dysk NVMe, przenieś katalog danych bazy danych. Różnica rzędu wielkości w IOPS sprawia, że jest to najskuteczniejsze dostępne rozwiązanie.

Ustaw odpowiedni harmonogram I/O. Nowoczesne jądra mają rozsądne ustawienia domyślne, ale warto to sprawdzić. W przypadku dysków NVMe i SSD ustaw harmonogram na none. Urządzenie radzi sobie z kolejkowaniem w sprzęcie lepiej niż jądro:

echo none > /sys/block/nvme0n1/queue/scheduler

W przypadku dysków HDD obsługujących mieszane obciążenia mq-deadline jest to typowy wybór.

Zamontuj z opcją noatime. Każdy odczyt domyślnie aktualizuje znacznik czasu ostatniego dostępu do pliku, generując operację zapisu przy każdym odczycie. W systemach plików intensywnie odczytujących jest to niepotrzebna operacja wejścia/wyjścia. Dodaj noatime do opcji montowania w /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Dostosuj zapis zwrotny dla nagłych zapisów. Na serwerach z dużą ilością pamięci RAM domyślne progi brudnych stron pozwalają pamięci podręcznej stron gromadzić gigabajty nie zapisanych danych, a następnie opróżniać ją w jednym dużym cyklu. Obniż progi w /etc/sysctl.conf , aby to wyrównać:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Sam dysk zazwyczaj nie stanowi problemu. Gdy iostat pokazuje wysokie IOPS i niską przepustowość, obciążenie wykonuje losowe operacje wejścia/wyjścia na danych, które mogłyby być sekwencyjne, lub wykonuje wiele małych operacji zapisu, które mogłyby być zgrupowane. Zanim obwiniasz sprzęt, przyjrzyj się aplikacji.

Jeśli uruchamiasz obciążenia wymagające dużej ilości pamięci na serwerze, na którym sieć może wyprzedzać dysk, serwery dedykowane FDC oparte na NVMe zapewniają wystarczającą rezerwę mocy, aby efektywnie zastosować powyższe optymalizacje.