iostat och iotop: diagnostisera flaskhalsar i Linux-lagring

När en Linux-server känns långsam är lagringen ett av de första ställena att titta på. iostat visar om disken är överbelastad; iotop visar vilken process som orsakar belastningen. Tillsammans besvarar de de två frågorna som är viktiga: är disken verkligen flaskhalsen, och i så fall, vad är det som belastar den? Det här inlägget täcker installation, hur man läser utdata (inklusive var iostats %util metrik finns på modern hårdvara) samt ett arbetsflöde för att gå från symptom till lösning.

Installera iostat och iotop

iostat ingår i sysstat-paketet; iotop levereras separat. Installera båda:

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

I Ubuntu levereras sysstat inaktiverat. För att samla in bakgrundsdata för senare analys med sar, redigera /etc/default/sysstat, ställ in ENABLED="true"och starta om tjänsten:

sudo systemctl restart sysstat

iotop måste köras som root. På RHEL 9 och nyare är fördröjningsredovisning inaktiverad som standard, vilket lämnar IO och SWAPIN kolumnerna tomma. Aktivera det med:

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

Lägg till kernel.task_delayacct = 1 till /etc/sysctl.conf för att göra det beständigt över omstarter.

Läsa iostat-utdata

Kör iostat med utökad statistik och ignorera det första exemplet, som endast visar genomsnitt sedan uppstart:

iostat -xz 2

Flaggan -x flaggan lägger till utökad statistik, -z döljer inaktiva enheter, och 2 uppdateras varannan sekund. De kolumner som är viktiga:

• await: genomsnittlig tid i millisekunder för att en I/O-begäran ska slutföras, inklusive kötid. Det enskilt viktigaste talet när användare klagar på långsamhet.
• r/s och w/s: läs- och skriv-IOPS. I kombination med rkB/s och wkB/s dessa tal kan du avgöra om din arbetsbelastning är slumpmässig (hög IOPS, låg genomströmning) eller sekventiell (låg IOPS, hög genomströmning).
• aqu-sz: genomsnittligt ködjup. För HDD:er innebär allt som ligger över 1 att disken inte hinner med.
• %util: procentandel av tiden som enheten hade minst en pågående I/O. Användbart för HDD, missvisande för NVMe (se nedan).

En snabb referens för tröskelvärden:

Var %util ligger

%util är det mått som de flesta först tittar på, och på NVMe är det aktivt missvisande. Kärnan räknar %util som ”all I/O som pågår vid varje given tidpunkt”, vilket fungerar bra för en roterande disk som bearbetar en begäran i taget men är meningslöst för NVMe-enheter som hanterar tusentals begäranden parallellt över hårdvaruköer. En NVMe-enhet kan ligga på 100 % %util medan den arbetar med 5 % av sin verkliga kapacitet.

På NVMe, lita på r_await, w_awaitoch aqu-sz istället. Om r_await ligger under 1 ms och ködjupet ligger bekvämt under enhetens hårdvaruködjup (ofta 1024 eller högre) är enheten inte egentligen mättad oavsett vad %util säger.

För en snabb NVMe-vy i MB/s istället för kB/s:

iostat -xm 1

För långsiktig insamling kan du senare korrelera med applikationsloggar:

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

Det tar prover var 5:e sekund under en timme. sar från samma sysstat-paket ger dig motsvarande data med beständig historisk lagring och är det bättre valet för löpande övervakning.

Bekräfta med CPU iowait

Om iostat visar lagringsbelastning, dubbelkolla med %iowait kolumnen i CPU-sammanfattningen högst upp i samma utdata. En ihållande %iowait över 15–20 % tillsammans med hög await bekräftar att flaskhalsen är lagringen. Om %iowait är högt men await ser normalt ut, kör vmstat 1 och kontrollera si och so . Swap-aktivitet som inte är noll innebär att du är minnesbegränsad och att disktrafiken är sidväxling, inte applikations-I/O.

Läsa iotop-utdata

När iostat har bekräftat en lagringsflaskhals, visar iotop vilken process som är ansvarig. Börja med:

sudo iotop -o

Flaggan -o flaggan döljer inaktiva processer och lämnar endast kvar de som aktivt utför I/O. Kolumnerna att hålla koll på:

• DISK READ / DISK WRITE: realtidsgenomströmning per process. Identifierar de uppenbara tungviktarna.
• IO: procentandel av tiden som processen är blockerad på I/O. En process som skriver bara 50 kB/s kan visa 99 % IO om den utför små synkrona fsync() anrop. Denna kolumn är viktigare än den råa genomströmningen.
• SWAPIN: procentandel av tiden som väntar på swap-sidor. Ett värde som inte är noll här betyder att systemet paginerar och att ditt ”lagringsproblem” egentligen är ett minnesproblem.

För flertrådade applikationer (MySQL, PostgreSQL, Java-arbetsbelastningar), slå ihop trådarna tillbaka till processer med -Poch lägg till -a för att ackumulera totaler sedan iotop startade:

sudo iotop -oPa

Flaggan -a är tricket för att fånga upp sporadiska arbetsbelastningar som säkerhetskopieringsjobb som bara körs i några sekunder åt gången och som annars skulle vara svåra att upptäcka i en livevy.

För obevakad loggning under nattfönster när ingen tittar:

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

Det skriver en icke-interaktiv ögonblicksbild var 10:e sekund. Kombinera det med tidsstämplar från dina säkerhetskopierings- eller cron-jobb för att hitta den skyldige i efterhand.

Ett diagnostiskt arbetsflöde

De flesta undersökningar av disk-I/O följer samma mönster:

1. iostat -xz 2 för att bekräfta att disken faktiskt är flaskhalsen. Titta på await, aqu-szoch %iowait. Om dessa är normala är problemet inte lagringen och du bör leta någon helt annanstans.
2. iotop -oPa för att hitta den process som driver belastningen. Titta mer på IO-kolumnen än på genomströmningskolumnen. De värsta syndarna är ofta program som utför många små synkrona skrivningar, inte de som flyttar flest byte.
3. lsof -p <pid> för att se vilka filer processen påverkar. Detta identifierar vanligtvis arbetsbelastningstypen omedelbart: en databas-write-ahead-logg, en applikationsloggfil, en backup-monteringspunkt, en temporär fil.

Två mönster som är värda att känna till.

Om du ser kärntrådar som jbd2/... (ext4 journal) eller txg_sync (ZFS) högst upp bland iotops skrivare, svarar de på skrivningar från andra processer, inte initierar dem. Användarutrymmesprocessen som driver journaltrafiken är den egentliga orsaken; fortsätt att gräva.

På en VPS kan hög await med låg %util är det klassiska tecknet på en störande granne. En annan hyresgäst monopoliserar det delade lagringsutrymmet och din I/O köar på hypervisorsidan, inte på din virtuella disk. Du kan bekräfta men inte åtgärda detta inifrån gästen; lösningen är antingen att eskalera till leverantören eller att flytta till en server med isolerat lagringsutrymme.

Åtgärda vanliga I/O-flaskhalsar

När du väl vet vad som belastar disken är lösningarna oftast enkla.

Sänk prioriteten för icke-kritisk I/O. ionice placerar en process i den inaktiva schemaläggningsklassen, där den endast använder diskbandbredd när inget annat behöver den:

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

Den första formen ändrar en pågående process; den andra startar en ny som redan finns i viloklassen. Inuti iotop kan du ändra prioriteten på en pågående process interaktivt genom att trycka på i.

Flytta intensiva arbetsbelastningar till snabbare lagring. Om iostat visar att en SATA-disk är överbelastad av databasskrivningar och det finns en ledig NVMe i samma enhet, flytta databasens datakatalog. Den enorma skillnaden i IOPS gör detta till den mest effektiva lösningen som finns.

Ställ in rätt I/O-schemaläggare. Moderna kärnor har rimliga standardinställningar, men det är värt att kontrollera. För NVMe och SSD-enheter, ställ in schemaläggaren till none. Enheten hanterar köer i hårdvaran bättre än kärnan kan:

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

För HDD-enheter som hanterar blandade arbetsbelastningar mq-deadline är det vanliga valet.

Montera med noatime. Varje läsning uppdaterar som standard filens tidsstämpel för senaste åtkomst, vilket genererar en skrivning för varje läsning. På läsintensiva filsystem är detta onödig I/O. Lägg till noatime till monteringsalternativen i /etc/fstab:

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

Justera writeback för sporadiska skrivningar. På servrar med gott om RAM-minne låter standardtrösklarna för smutsiga sidor sidcachen ackumulera gigabyte av oskrivna data, för att sedan tömma den i en stor omgång. Sänk trösklarna i /etc/sysctl.conf för att jämna ut detta:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Själva disken är vanligtvis inte problemet. När iostat visar höga IOPS och låg genomströmning utför arbetsbelastningen slumpmässig I/O på data som skulle kunna vara sekventiell, eller kör många små skrivningar som skulle kunna batchas. Titta på applikationen innan du skyller på hårdvaran.

Om du kör lagringskrävande arbetsbelastningar på en server där nätverket kan köra ifrån disken, ger FDC:s NVMe-baserade dedikerade servrar dig utrymmet att tillämpa ovanstående optimering på ett produktivt sätt.