iostat e iotop: diagnosi dei colli di bottiglia dello storage Linux

Quando un server Linux sembra lento, lo storage è uno dei primi posti da controllare. iostat mostra se il disco è sovraccarico; iotop mostra quale processo sta causando il carico. Usati insieme, rispondono alle due domande fondamentali: il disco è effettivamente il collo di bottiglia e, in tal caso, cosa lo sta sovraccaricando? Questo post tratta l'installazione, come leggere l'output (compreso dove si trova la %util si trova su hardware moderno) e un flusso di lavoro per passare dal sintomo alla soluzione.

Installazione di iostat e iotop

iostat è incluso nel pacchetto sysstat; iotop viene fornito separatamente. Installare entrambi:

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

Su Ubuntu, sysstat viene fornito disabilitato. Per raccogliere dati in background da analizzare in seguito con sar, modificare /etc/default/sysstat, impostare ENABLED="true"e riavviare il servizio:

sudo systemctl restart sysstat

iotop deve essere eseguito come root. Su RHEL 9 e versioni successive, il conteggio dei ritardi è disabilitato per impostazione predefinita, il che lascia il IO e SWAPIN vuote. Abilitalo con:

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

Aggiungere kernel.task_delayacct = 1 a /etc/sysctl.conf per renderlo persistente anche dopo il riavvio.

Lettura dell'output di iostat

Eseguire iostat con statistiche estese e ignorare il primo campione, che mostra solo le medie dal momento dell'avvio:

iostat -xz 2

Il -x flag aggiunge statistiche estese, -z nasconde i dispositivi inattivi e l' 2 aggiorna ogni due secondi. Le colonne che contano:

• await: tempo medio in millisecondi necessario per il completamento di una richiesta di I/O, compreso il tempo di attesa in coda. Il dato più importante in assoluto quando gli utenti lamentano la lentezza del sistema.
• r/s e w/s: IOPS di lettura e scrittura. In combinazione con rkB/s e wkB/s questi indicatori ti dicono se il tuo carico di lavoro è casuale (alto numero di IOPS, basso throughput) o sequenziale (basso numero di IOPS, alto throughput).
• aqu-sz: profondità media della coda. Per gli HDD, qualsiasi valore superiore a 1 significa che il disco non riesce a stare al passo.
• %util: percentuale di tempo in cui il dispositivo ha avuto almeno un I/O in corso. Utile sugli HDD, fuorviante su NVMe (vedi sotto).

Un rapido riferimento alle soglie:

Dove si trova %util

%util è la metrica a cui la maggior parte delle persone ricorre per prima, e su NVMe è decisamente fuorviante. Il kernel considera %util come "qualsiasi I/O in corso in qualsiasi momento", il che va bene per un disco rotante che elabora una richiesta alla volta, ma è insignificante per i dispositivi NVMe che gestiscono migliaia di richieste in parallelo attraverso le code hardware. Un'unità NVMe può rimanere al 100% %util mentre funziona al 5% della sua capacità effettiva.

Su NVMe, fidatevi r_await, w_awaite aqu-sz invece. Se r_await rimane sotto 1 ms e la profondità della coda è ben al di sotto della profondità della coda hardware del dispositivo (spesso 1024 o superiore), l'unità non è effettivamente saturata indipendentemente da ciò che %util dica.

Per una visualizzazione veloce di NVMe in MB/s anziché in kB/s:

iostat -xm 1

Per una raccolta a lungo termine è possibile correlare i dati con i log delle applicazioni in un secondo momento:

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

Questo campiona ogni 5 secondi per un'ora. sar dallo stesso pacchetto sysstat fornisce dati equivalenti con archiviazione storica persistente ed è la scelta migliore per il monitoraggio continuo.

Conferma con CPU iowait

Se iostat mostra uno stress di archiviazione, effettuare un controllo incrociato con la %iowait colonna nel riepilogo della CPU nella parte superiore dello stesso output. Un %iowait superiore al 15-20% insieme a un alto await conferma che il collo di bottiglia è lo storage. Se %iowait è elevato ma await sembra normale, esegui vmstat 1 e controlla il si e so . Un'attività di swap diversa da zero significa che si è limitati dalla memoria e che il traffico su disco è dovuto al paging, non all'I/O dell'applicazione.

Lettura dell'output di iotop

Una volta che iostat ha confermato un collo di bottiglia nell'archiviazione, iotop indica quale processo ne è responsabile. Inizia con:

sudo iotop -o

Il -o nasconde i processi inattivi, lasciando solo quelli che stanno attivamente eseguendo operazioni di I/O. Le colonne da tenere d'occhio:

• DISK READ / DISK WRITE: throughput in tempo reale per processo. Identifica i processi che consumano più risorse.
• IO: percentuale di tempo in cui il processo è bloccato sull'I/O. Un processo che scrive solo 50 kB/s può mostrare un 99% di IO se sta effettuando piccole chiamate sincrone fsync() . Questa colonna è più importante della velocità effettiva.
• SWAPIN: percentuale di tempo trascorso in attesa delle pagine di swap. Un valore diverso da zero indica che il sistema sta utilizzando lo swap e che il vostro "problema di storage" è in realtà un problema di memoria.

Per le applicazioni multithread (MySQL, PostgreSQL, carichi di lavoro Java), raggruppare i thread nei processi -Pe sommare -a per accumulare i totali da quando iotop è stato avviato:

sudo iotop -oPa

Il -a flag è il trucco per rilevare carichi di lavoro a raffica come i processi di backup che girano solo per pochi secondi alla volta e che altrimenti sarebbero difficili da individuare in una vista live.

Per la registrazione automatica durante le finestre notturne quando nessuno sta guardando:

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

Questo scrive un'istantanea non interattiva ogni 10 secondi. Abbinatela ai timestamp dei vostri processi di backup o cron per individuare il colpevole a posteriori.

Un flusso di lavoro diagnostico

La maggior parte delle indagini sull'I/O del disco segue lo stesso percorso:

1. iostat -xz 2 per confermare che il disco sia effettivamente il collo di bottiglia. Guarda await, aqu-sze %iowait. Se questi sono normali, il problema non è lo storage e dovresti cercare altrove.
2. iotop -oPa per individuare il processo che genera il carico. Osservare la colonna IO più che quella del throughput. I principali responsabili sono spesso i programmi che eseguono molte piccole scritture sincrone, non quelli che trasferiscono il maggior numero di byte.
3. lsof -p <pid> per vedere quali file sta utilizzando quel processo. Questo di solito identifica immediatamente il tipo di carico di lavoro: un log di scrittura anticipata del database, un file di log dell’applicazione, un punto di montaggio di backup, un file temporaneo.

Due modelli che vale la pena conoscere.

Se vedete thread del kernel come jbd2/... (ext4 journal) o txg_sync (ZFS) in cima agli scrittori di iotop, questi stanno rispondendo a scritture da altri processi, non le stanno avviando. Il processo dello spazio utente che genera il traffico del journal è la causa effettiva; continua a indagare.

Su un VPS, un await con basso %util è il classico segnale di un "vicino rumoroso". Un altro utente sta monopolizzando lo storage condiviso e il tuo I/O è in coda sul lato dell'hypervisor, non sul tuo disco virtuale. Puoi confermarlo ma non risolverlo dall'interno del guest; la soluzione è segnalare il problema al provider o passare a un server con storage isolato.

Risoluzione dei comuni colli di bottiglia I/O

Una volta individuato il problema che interessa il disco, le soluzioni sono solitamente semplici.

Ridurre la priorità dell'I/O non critico. ionice mette un processo nella classe di scheduling idle, dove usa la larghezza di banda del disco solo quando nessun altro la richiede:

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

La prima forma modifica un processo in esecuzione; la seconda ne avvia uno nuovo già nella classe di inattività. All'interno di iotop, è possibile modificare la priorità di un processo in esecuzione in modo interattivo premendo i.

Spostare i carichi di lavoro più intensi su uno storage più veloce. Se iostat mostra un disco SATA sovraccarico a causa delle scritture del database e c'è un NVMe inattivo nello stesso box, spostare la directory dei dati del database. La differenza di ordine di grandezza in termini di IOPS rende questa soluzione la più efficace a disposizione.

Impostare lo scheduler I/O corretto. I kernel moderni hanno impostazioni predefinite ragionevoli, ma vale la pena controllare. Per NVMe e SSD, impostare lo scheduler su none. Il dispositivo gestisce l'accodamento a livello hardware meglio di quanto possa fare il kernel:

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

Per gli HDD che gestiscono carichi di lavoro misti, mq-deadline è la scelta usuale.

Montare con noatime. Per impostazione predefinita, ogni lettura aggiorna il timestamp dell'ultimo accesso del file, generando una scrittura per ogni lettura. Su filesystem con un'elevata attività di lettura, si tratta di I/O superfluo. Aggiungere noatime alle opzioni di montaggio in /etc/fstab:

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

Ottimizzare il writeback per le scritture a raffica. Su server con molta RAM, le soglie predefinite delle pagine sporche consentono alla cache delle pagine di accumulare gigabyte di dati non scritti, per poi scaricarli in un unico grande blocco. Abbassare le soglie in /etc/sysctl.conf per appianare questo problema:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Il disco in sé di solito non è il problema. Quando iostat mostra IOPS elevati e un throughput basso, il carico di lavoro sta eseguendo operazioni di I/O casuali su dati che potrebbero essere sequenziali, oppure sta eseguendo molte piccole operazioni di scrittura che potrebbero essere raggruppate in batch. Esamina l'applicazione prima di dare la colpa all'hardware.

Se si eseguono carichi di lavoro che richiedono un uso intensivo dello storage su un server in cui la rete può superare la velocità del disco, i server dedicati supportati da NVMe di FDC offrono il margine necessario per applicare in modo produttivo l'ottimizzazione sopra descritta.