iostat és iotop: a Linux tárolási szűk keresztmetszeteinek diagnosztizálása

Ha egy Linux-szerver lassúnak tűnik, az egyik első hely, ahol meg kell nézni, a tároló. Az iostat megmutatja, hogy a lemez túlterhelt-e; az iotop pedig azt, hogy melyik folyamat okozza a terhelést. Együttesen használva megválaszolják a két fontos kérdést: valóban a lemez a szűk keresztmetszet, és ha igen, mi terheli túl? Ez a bejegyzés a telepítést, a kimenet értelmezését (beleértve azt is, hogy hol található az iostat %util mutatója található a modern hardverekben), valamint a tünettől a javításig vezető munkafolyamatot.

Az iostat és az iotop telepítése

Az iostat a sysstat csomag része; az iotop külön szállítják. Telepítse mindkettőt:

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

Ubuntun a sysstat letiltva érkezik. A későbbi elemzéshez szükséges háttéradatok gyűjtéséhez sar, szerkessze /etc/default/sysstat, állítsa be ENABLED="true", majd indítsa újra a szolgáltatást:

sudo systemctl restart sysstat

Az iotop-nak rootként kell futnia. RHEL 9 és újabb verziókon a késleltetés-nyilvántartás alapértelmezés szerint ki van kapcsolva, ami a IO és SWAPIN oszlopok üresek maradnak. Engedélyezze a következő paranccsal:

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

Add kernel.task_delayacct = 1 a /etc/sysctl.conf , hogy az újraindítás után is megmaradjon.

Az iostat kimenetének olvasása

Futtassa az iostat parancsot kiterjesztett statisztikákkal, és hagyja figyelmen kívül az első mintát, amely csak a rendszerindítás óta mért átlagokat mutatja:

iostat -xz 2

Az -x flag kiterjesztett statisztikákat ad hozzá, -z elrejti az inaktív eszközöket, a 2 két másodpercenként frissít. A fontos oszlopok:

• await: az I/O-kérés teljesítésének átlagos ideje milliszekundumokban, beleértve a várakozási időt is. Ez a legfontosabb szám, amikor a felhasználók a lassúságra panaszkodnak.
• r/s és w/s: olvasási és írási IOPS. A rkB/s és wkB/s ezekből megtudhatja, hogy a terhelése véletlenszerű (magas IOPS, alacsony átviteli sebesség) vagy szekvenciális (alacsony IOPS, magas átviteli sebesség).
• aqu-sz: átlagos sorhossz. HDD-k esetében minden 1 feletti érték azt jelenti, hogy a lemez nem bírja a tempót.
• %util: az idő százalékos aránya, amikor az eszköznek legalább egy folyamatban lévő I/O-ja volt. Hasznos HDD-knél, félrevezető NVMe-nél (lásd alább).

Gyors küszöbérték-referencia:

Ahol a %util található

%util az a mutató, amelyhez a legtöbb ember először nyúl, és az NVMe esetében ez aktívan félrevezető. A kernel %util „bármely pillanatban folyamatban lévő bármely I/O-t”, ami rendben van egy forgólemez esetében, amely egyszerre egy kérést dolgoz fel, de értelmetlen az NVMe-eszközök esetében, amelyek több ezer kérést kezelnek párhuzamosan a hardveres sorokban. Egy NVMe-meghajtó 100%-on állhat %util , miközben a tényleges kapacitásának 5%-án működik.

NVMe esetén bízz r_await, w_await, és aqu-sz ezt. Ha r_await 1 ms alatt marad, és a sor mélysége jóval az eszköz hardveres sorának mélysége alatt van (gyakran 1024 vagy annál nagyobb), a meghajtó valójában nem telített, függetlenül attól, hogy mit %util mondja.

A gyors NVMe-meghajtók esetében a kB/s helyett MB/s-ban érdemes nézni:

iostat -xm 1

Hosszú távú adatgyűjtés esetén később összevetheted az alkalmazásnaplókkal:

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

Ez egy órán át 5 másodpercenként vesz mintát. sar Ugyanabból a sysstat csomagból származó adatokkal ugyanazokat az adatokat kapja, de azok tartósan tárolódnak, így ez a jobb választás a folyamatos figyeléshez.

Ellenőrzés a CPU iowait segítségével

Ha az iostat tárolási terhelést jelez, ellenőrizze a %iowait oszlopot a kimenet tetején található CPU-összefoglalóban. A tartós %iowait 15-20% feletti érték és a magas await értékkel együtt megerősíti, hogy a szűk keresztmetszet a tároló. Ha %iowait magas, de await normálisnak tűnik, futtassa a vmstat 1 és ellenőrizze a si és so oszlopokat. A nullától eltérő swap-aktivitás azt jelenti, hogy memóriakorlát van, és a lemezforgalom lapozásból származik, nem pedig alkalmazás-I/O-ból.

Az iotop kimenetének olvasása

Miután az iostat megerősítette a tárolási szűk keresztmetszetet, az iotop megmutatja, melyik folyamat felelős érte. Kezdje a következőkkel:

sudo iotop -o

Az -o flag elrejti az üresjáratban lévő folyamatokat, csak azokat hagyja meg, amelyek aktívan végeznek I/O műveleteket. A figyelendő oszlopok:

• DISK READ / DISK WRITE: folyamatonkénti valós idejű átviteli sebesség. Meghatározza a nyilvánvalóan nagy terhelést okozó folyamatokat.
• IO: az idő százalékos aránya, amely alatt a folyamat I/O-n blokkolódik. Egy folyamat, amely csupán 50 kB/s sebességgel ír, 99%-os IO-t mutathat, ha apró szinkron fsync() hívásokat hajt végre. Ez az oszlop fontosabb, mint a nyers átviteli sebesség.
• SWAPIN: a swap-oldalakra várakozással töltött idő százalékos aránya. Ha itt a érték nem nulla, az azt jelenti, hogy a rendszer lapozik, és az Ön „tárolási problémája” valójában memóriaprobléma.

Többszálas alkalmazások (MySQL, PostgreSQL, Java terhelések) esetén összesítse a szálakat folyamatokká a -P, és adja hozzá -a az iotop indítása óta felhalmozódott összegeket:

sudo iotop -oPa

A -a flag a trükk a robbanásszerű terhelések, például a biztonsági mentési feladatok észleléséhez, amelyek egyszerre csak néhány másodpercig futnak, és egyébként nehéz lenne észrevenni őket az élő nézetben.

Felügyelet nélküli naplózáshoz éjszakai időszakokban, amikor senki sem figyel:

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

Ez 10 másodpercenként ír egy nem interaktív pillanatképet. Párosítsa a biztonsági mentési vagy cron feladatok időbélyegeivel, hogy utólag megtalálja a hibás elemet.

Diagnosztikai munkafolyamat

A legtöbb lemez-I/O vizsgálat ugyanazt a folyamatot követi:

1. iostat -xz 2 hogy megerősítsék, valóban a lemez a szűk keresztmetszet. Nézze meg await, aqu-sz, és %iowait. Ha ezek normálisak, a probléma nem a tárolóban van, és teljesen máshol kell keresnie.
2. iotop -oPa hogy megtalálja a terhelést okozó folyamatot. Figyelje inkább az IO oszlopot, mint az átviteli sebesség oszlopot. A legrosszabb bűnösök gyakran azok a programok, amelyek sok kis szinkron írási műveletet hajtanak végre, nem pedig azok, amelyek a legtöbb bájtot mozgatják.
3. lsof -p <pid> hogy megnézze, mely fájlokat érint az adott folyamat. Ez általában azonnal azonosítja a terhelés típusát: adatbázis előreírási napló, alkalmazás naplófájl, biztonsági mentési csatlakozási pont, ideiglenes fájl.

Két tudnivaló minta.

Ha olyan kernel szálakat lát, mint jbd2/... (ext4 journal) vagy txg_sync (ZFS) jelennek meg az iotop írói között, azok más folyamatok írásaira reagálnak, nem pedig kezdeményezik azokat. A napló forgalmát generáló felhasználói térbeli folyamat a valódi ok; folytassa a kutatást.

VPS-en a magas await és alacsony %util érték a klasszikus „zajos szomszéd” jel. Egy másik bérlő monopolizálja a megosztott tárolót, és az I/O-ja a hipervizor oldalán sorba áll, nem a virtuális lemezen. Ezt a vendégrendszeren belül ellenőrizheti, de nem tudja kijavítani; a megoldás vagy a szolgáltatóhoz fordulni, vagy egy izolált tárolóval rendelkező szerverre váltani.

Gyakori I/O-szűk keresztmetszetek kijavítása

Ha már tudjuk, mi terheli a lemezt, a javítás általában egyszerű.

Csökkentse a nem kritikus I/O prioritását. ionice A parancs a folyamatot az üresjárati ütemezési osztályba helyezi, ahol csak akkor használja a lemez sávszélességét, ha más nem igényli azt:

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

Az első forma egy futó folyamatot módosít; a második egy újat indít, amely már az üresjárati osztályban van. Az iotop-on belül az i gomb megnyomásával interaktív módon módosíthatja a futó folyamat prioritását.

A forgalmas munkaterheléseket helyezze át gyorsabb tárolóra. Ha az iostat azt mutatja, hogy egy SATA lemez túlterhelt az adatbázis írási műveletei miatt, és ugyanabban a gépen van egy kihasználatlan NVMe, helyezze át az adatbázis adatkönyvtárát. Az IOPS nagyságrendbeli különbsége miatt ez a leghatékonyabb megoldás.

Állítsa be a megfelelő I/O ütemezőt. A modern kerneltípusok alapértelmezései ésszerűek, de érdemes ellenőrizni. NVMe és SSD esetében állítsa az ütemezőt noneértékre. Az eszköz hardveresen jobban kezeli a sorbaállítást, mint a rendszermag:

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

Vegyes terhelést kezelő HDD-k esetében mq-deadline a szokásos választás.

Csatlakoztassa noatime-mal. Alapértelmezés szerint minden olvasás frissíti a fájl utolsó hozzáférési időbélyegét, így minden olvasás írási műveletet generál. Olvasásintenzív fájlrendszereken ez felesleges I/O. Adja hozzá noatime a csatlakoztatási opciókhoz a /etc/fstab:

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

Állítsa be a writeback-et a rohamokban érkező írásokhoz. A bőséges RAM-mal rendelkező szervereken az alapértelmezett piszkos oldal küszöbértékek lehetővé teszik, hogy az oldalgyorsítótár gigabájtnyi le nem írt adatot halmozzon fel, majd egy nagy leállás során ürítse ki. Csökkentse a küszöbértékeket a /etc/sysctl.conf , hogy ezt kiegyenlítse:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Maga a lemez általában nem jelent problémát. Ha az iostat magas IOPS-értéket és alacsony átviteli sebességet jelez, akkor a terhelés véletlenszerű I/O-t hajt végre olyan adatokon, amelyek szekvenciálisak lehetnének, vagy sok kis írási műveletet futtat, amelyeket kötegelt feldolgozás keretében is el lehetne végezni. Mielőtt a hardvert hibáztatná, vizsgálja meg az alkalmazást.

Ha tárolásigényes terheléseket futtat egy olyan szerveren, ahol a hálózat gyorsabb lehet a lemezenél, az FDC NVMe-alapú dedikált szerverei elegendő kapacitást biztosítanak a fenti beállítások hatékony alkalmazásához.