iostat en iotop: het opsporen van knelpunten in Linux-opslag

Wanneer een Linux-server traag aanvoelt, is opslag een van de eerste plaatsen om te controleren. iostat laat zien of de schijf overbelast is; iotop laat zien welk proces de belasting veroorzaakt. Samen geven ze antwoord op de twee belangrijke vragen: is de schijf daadwerkelijk de bottleneck, en zo ja, wat belast deze dan? Dit bericht behandelt de installatie, hoe je de uitvoer leest (inclusief waar de %util op moderne hardware), en een workflow om van symptoom naar oplossing te gaan.

iostat en iotop installeren

iostat wordt meegeleverd met het sysstat-pakket; iotop wordt apart geleverd. Installeer beide:

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

Op Ubuntu wordt sysstat uitgeschakeld geleverd. Om achtergrondgegevens te verzamelen voor latere analyse met sar, bewerk /etc/default/sysstat, stel ENABLED="true"en start de service opnieuw:

sudo systemctl restart sysstat

iotop moet als root worden uitgevoerd. Op RHEL 9 en nieuwer is delay accounting standaard uitgeschakeld, waardoor de IO en SWAPIN kolommen leeg blijven. Schakel het in met:

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

Voeg kernel.task_delayacct = 1 aan /etc/sysctl.conf om ervoor te zorgen dat het na een herstart behouden blijft.

De uitvoer van iostat lezen

Voer iostat uit met uitgebreide statistieken en negeer het eerste voorbeeld, dat alleen gemiddelden sinds het opstarten weergeeft:

iostat -xz 2

De -x vlag voegt uitgebreide statistieken toe, -z verbergt inactieve apparaten en de 2 verversen de gegevens elke twee seconden. De kolommen die ertoe doen:

• await: gemiddelde tijd in milliseconden die een I/O-verzoek nodig heeft om te voltooien, inclusief wachttijd. Het allerbelangrijkste getal wanneer gebruikers klagen over traagheid.
• r/s en w/s: lees- en schrijf-IOPS. Gecombineerd met rkB/s en wkB/s deze geven aan of uw werklast willekeurig is (hoge IOPS, lage doorvoer) of sequentieel (lage IOPS, hoge doorvoer).
• aqu-sz: gemiddelde wachtrijdiepte. Voor HDD's betekent een waarde die constant boven de 1 ligt dat de schijf het niet bij kan houden.
• %util: percentage van de tijd dat het apparaat ten minste één lopende I/O had. Nuttig bij HDD's, misleidend bij NVMe (zie hieronder).

Een korte drempelwaarderichtlijn:

Waar %util ligt

%util is de statistiek waar de meeste mensen als eerste naar kijken, en bij NVMe is deze actief misleidend. De kernel telt %util "elke I/O die op dat moment bezig is", wat prima is voor een draaiende schijf die één verzoek tegelijk verwerkt, maar zinloos is voor NVMe-apparaten die duizenden verzoeken parallel verwerken via hardwarewachtrijen. Een NVMe-schijf kan op 100% staan %util terwijl hij op 5% van zijn werkelijke capaciteit werkt.

Vertrouw op NVMe r_await, w_awaiten aqu-sz in plaats daarvan. Als r_await blijft onder de 1 ms en de wachtrijdiepte ruim onder de hardware-wachtrijdiepte van het apparaat ligt (vaak 1024 of hoger), is de schijf in feite niet verzadigd, ongeacht wat %util zegt.

Voor een snel NVMe-overzicht in MB/s in plaats van kB/s:

iostat -xm 1

Voor het verzamelen van gegevens op de lange termijn kun je later correleren met applicatielogboeken:

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

Dat neemt gedurende een uur elke 5 seconden een steekproef. sar uit hetzelfde sysstat-pakket geeft je de equivalente gegevens met permanente historische opslag en is de betere keuze voor doorlopende monitoring.

Bevestigen met CPU iowait

Als iostat opslagbelasting aangeeft, controleer dit dan met de %iowait kolom in het CPU-overzicht bovenaan dezelfde uitvoer. Aanhoudende %iowait boven de 15-20% in combinatie met hoge await bevestigt dat de bottleneck de opslag is. Als %iowait hoog is maar await er normaal uitziet, voer dan vmstat 1 en controleer de si en so . Swap-activiteit die niet nul is, betekent dat je geheugenbeperkt bent en dat het schijfverkeer paging is, geen applicatie-I/O.

De uitvoer van iotop lezen

Zodra iostat een opslagbottleneck bevestigt, vertelt iotop je welk proces hiervoor verantwoordelijk is. Begin met:

sudo iotop -o

De -o vlag verbergt inactieve processen, waardoor alleen die overblijven die actief I/O uitvoeren. De kolommen om in de gaten te houden:

• DISK READ / DISK WRITE: realtime doorvoer per proces. Geeft de voor de hand liggende zware gebruikers aan.
• IO: percentage van de tijd dat het proces geblokkeerd is op I/O. Een proces dat slechts 50 kB/s schrijft, kan 99% IO vertonen als het kleine synchrone fsync() aanroepen uitvoert. Deze kolom is belangrijker dan de ruwe doorvoer.
• SWAPIN: percentage van de tijd dat er wordt gewacht op swap-pagina's. Een waarde anders dan nul betekent hier dat het systeem aan paging doet en dat uw "opslagprobleem" in werkelijkheid een geheugenprobleem is.

Voor multithreaded applicaties (MySQL, PostgreSQL, Java-workloads) moet u threads weer samenvoegen tot processen met -P, en tel -a om de totalen sinds de start van iotop op te tellen:

sudo iotop -oPa

De -a vlag is de truc om pieken in de werklast op te vangen, zoals back-uptaken die slechts enkele seconden per keer draaien en anders moeilijk te herkennen zouden zijn in een liveweergave.

Voor onbemande logboekregistratie tijdens nachtelijke vensters wanneer niemand kijkt:

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

Dat schrijft elke 10 seconden een niet-interactieve momentopname. Combineer dit met tijdstempels van je back-up- of cron-taken om achteraf de boosdoener te vinden.

Een diagnostische workflow

De meeste onderzoeken naar schijf-I/O volgen hetzelfde pad:

1. iostat -xz 2 om te bevestigen dat de schijf daadwerkelijk de bottleneck is. Bekijk await, aqu-sz, en %iowait. Als deze normaal zijn, ligt het probleem niet bij de opslag en moet u ergens anders zoeken.
2. iotop -oPa om het proces te vinden dat de belasting veroorzaakt. Let meer op de IO-kolom dan op de doorvoerkolom. De grootste boosdoeners zijn vaak programma's die veel kleine synchrone schrijfbewerkingen uitvoeren, niet de programma's die de meeste bytes verplaatsen.
3. lsof -p <pid> om te zien welke bestanden dat proces aanraakt. Dit identificeert meestal onmiddellijk het type werklast: een database write-ahead log, een applicatielogbestand, een back-up mountpunt, een tijdelijk bestand.

Twee patronen die de moeite waard zijn om te kennen.

Als u kernelthreads ziet zoals jbd2/... (ext4-journaal) of txg_sync (ZFS) bovenaan de schrijvers van iotop ziet, reageren deze op schrijfbewerkingen van andere processen en initiëren ze deze niet. Het gebruikersruimteproces dat het journaalverkeer veroorzaakt, is de werkelijke oorzaak; ga verder met zoeken.

Op een VPS duidt een hoge await met laag %util is het klassieke signaal van een 'noisy neighbour'. Een andere tenant monopoliseert de gedeelde opslag en uw I/O staat in de wachtrij aan de hypervisor-kant, niet op uw virtuele schijf. U kunt dit vanuit de gast bevestigen, maar niet oplossen; de oplossing is ofwel escaleren naar de provider ofwel overstappen naar een server met geïsoleerde opslag.

Veelvoorkomende I/O-bottlenecks verhelpen

Zodra u weet wat de schijf belast, zijn de oplossingen meestal eenvoudig.

Verlaag de prioriteit van niet-kritische I/O. ionice plaatst een proces in de idle-schedulingklasse, waar het alleen schijfbandbreedte gebruikt als niets anders erom vraagt:

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

De eerste vorm wijzigt een lopend proces; de tweede start een nieuw proces dat al in de idle-klasse zit. Binnen iotop kunt u de prioriteit van een lopend proces interactief wijzigen door op i te drukken.

Verplaats intensieve workloads naar snellere opslag. Als iostat een SATA-schijf laat zien die overbelast is door schrijfbewerkingen van de database en er een inactieve NVMe in dezelfde behuizing zit, verplaats dan de gegevensmap van de database. Het enorme verschil in IOPS maakt dit de oplossing met het grootste effect.

Stel de juiste I/O-scheduler in. Moderne kernels hebben redelijke standaardinstellingen, maar het is de moeite waard om dit te controleren. Stel voor NVMe en SSD's de scheduler in op none. Het apparaat kan wachtrijen in de hardware beter verwerken dan de kernel:

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

Voor HDD's die gemengde workloads verwerken, mq-deadline is de gebruikelijke keuze.

Koppel met noatime. Elke leesbewerking werkt standaard de tijdstempel van de laatste toegang tot het bestand bij, waardoor elke leesbewerking een schrijfbewerking genereert. Op bestandssystemen met veel leesbewerkingen is dit onnodige I/O. Voeg noatime aan de mount-opties in /etc/fstab:

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

Stel writeback in voor bursty schrijfbewerkingen. Op servers met veel RAM zorgen de standaard drempels voor vuile pagina's ervoor dat de paginacache gigabytes aan ongeschreven gegevens verzamelt, om deze vervolgens in één grote beurt leeg te maken. Verlaag de drempels in /etc/sysctl.conf om dit te egaliseren:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

De schijf zelf is meestal niet het probleem. Wanneer iostat hoge IOPS en lage doorvoer laat zien, voert de workload willekeurige I/O uit op gegevens die sequentieel zouden kunnen zijn, of voert het veel kleine schrijfbewerkingen uit die gebatcht zouden kunnen worden. Kijk naar de applicatie voordat u de hardware de schuld geeft.

Als u opslagintensieve workloads uitvoert op een server waar het netwerk de schijf kan overtreffen, bieden de door NVMe ondersteunde dedicated servers van FDC u de ruimte om de bovenstaande afstemming productief toe te passen.