Vai al contenuto 
Mostro passo dopo passo come l'analisi delle attese di I/O con iostat e vmstat rende visibili i colli di bottiglia e quali metriche dei server Linux contano per ottenere tempi di risposta rapidi. In questo modo, stabilisco soglie chiare, interpreto modelli tipici e suggerisco misure concrete per ottimizzare i tempi di risposta. I/O e CPU in.
Punti centrali
- iostat e vmstat forniscono una visione complementare del carico della CPU e dello storage.
- wa tramite 15-20% e %utile via 80% mostrano un collo di bottiglia I/O.
- attendere e avgqu-sz spiegare la latenza e le code.
- mpstat rileva un carico distribuito in modo non uniforme tra i core della CPU.
- Sintonizzazione varia da MySQL ai parametri e alla memoria del kernel.
Cosa si intende per attesa di I/O sui server Linux?
In caso di attesa I/O, la CPU attende in modo inattivo perché è in attesa di dispositivi di memoria o di rete più lenti, il che è noto come wa-in strumenti come top o vmstat. Valuto questa percentuale come il tempo in cui i thread si bloccano e le richieste vengono completate più tardi, cosa che gli utenti percepiscono direttamente come lentezza. Valori superiori a 10-20% spesso indicano un utilizzo completo del sistema Immagazzinamento-sottosistema, ad esempio quando HDD, array RAID o mount NFS sono utilizzati al massimo della loro capacità. Nelle configurazioni di hosting con database, le query non indicizzate e i picchi di scrittura comportano inutili tempi di attesa sul sistema. Disco. Se volete ripassare i concetti, potete trovare le nozioni di base su Comprendere l'I/O Wait, prima di andare all'allenamento.
Avvio rapido: leggere correttamente vmstat
Con vmstat, posso controllare i più importanti Linux-e riconoscere gli schemi iniziali senza grandi sforzi. La chiamata vmstat 1 10 fornisce dieci istantanee in cui presto particolare attenzione alle colonne wa (attesa I/O), bi/bo (I/O a blocchi) e si/so (swap). Per me, valori elevati di bo con un contemporaneo aumento di wa indicano molti accessi in scrittura bloccanti, il che spesso indica limiti di buffer o supporti lenti. Se si/so rimane a zero, ma wa aumenta in modo significativo, il sospetto è che si tratti di puro Immagazzinamento-limite. Negli host multicore, combino vmstat con mpstat -P ALL 1, perché l'attesa dell'I/O spesso riguarda solo singoli core e quindi in media appare più innocua di quanto non sia in realtà.
Immagine fine della CPU: us/sy/st, coda di esecuzione e commutazione di contesto
Con vmstat e mpstat leggo più di quanto non faccia solo wa: Alto noiIl lavoro applicativo "pesante" è illustrato nelle sezioni seguenti, sy indica il lavoro del kernel/driver, ad esempio con l'uso intensivo di I/O. Negli ambienti virtualizzati faccio attenzione a st (furto): Valori elevati di st significano che la macchina virtuale perde tempo di CPU, il che gonfia artificialmente le latenze con un modello di I/O identico. Confronto anche la coda di esecuzione (r in vmstat) con il numero di CPU: un r permanentemente più alto del numero di CPU indica una congestione della CPU, non della rete. Immagazzinamento. Molti cambiamenti di contesto (cs) in combinazione con piccole scritture sincrone sono un indicatore di modelli di I/O chiacchieroni. In questo modo evito di interpretare erroneamente la scarsità di CPU come un problema di I/O.
Conoscere iostat in modo approfondito: metriche importanti
iostat -x 1 mi dà l'estensione Disco-Metriche che descrivono chiaramente la latenza, l'utilizzo e le code. Avvio la misurazione dei picchi di carico e metto in relazione %util, await, svctm e avgqu-sz per distinguere causa ed effetto. Se %util sale a 90-100%, mentre anche await e avgqu-sz aumentano, vedo una saturazione. Piatto o un volume limitato. Se await mostra valori elevati con %util moderato, verifico che non vi siano interferenze dovute alla cache, ai limiti del controller o a singole richieste di grandi dimensioni. r/s e w/s portano la frequenza nel quadro, mentre MB_read e MB_wrtn spiegano il volume, che mi fornisce importanti valori comparativi per le configurazioni SSD e NVMe dedicate.
NVMe, SATA e RAID: il significato di %util, await e queue depth
Faccio una distinzione rigorosa tra i tipi di media: HDD mostra un livello più alto attendere-anche con un indizio moderato, perché i movimenti della testa dominano. SSD/NVMe scalano bene con il parallelismo, ed è per questo che un valore più alto di avgqu-sz può essere normale, purché attendere rimane entro i limiti. Su NVMe con code multiple di invio/completamento, leggo %util con più cautela: i singoli dispositivi possono essere al limite già a 60-70% se l'applicazione non genera sufficiente parallelismo o la profondità della coda (nr_richieste, profondità_coda) è troppo piccolo. Nella RAID Verifico se la dispersione dell'I/O casuale incontra dimensioni di stripe troppo piccole; quindi attendere e %utile in modo non uniforme sui dischi membri. Pertanto, guardo iostat per ogni dispositivo membro, non solo sul volume composito, per rendere visibili i punti caldi. Per i livelli strutturati in log (ad esempio, copy-on-write), mi aspetto latenze leggermente più elevate per le scritture, ma le compenso con finestre di writeback più ampie o con il batching lato app.
Flusso di lavoro diagnostico per lunghi tempi di attesa
Avvio ogni analisi in parallelo con vmstat 1 e iostat -x 1 in modo da poter vedere gli stati della CPU e lo stato dei dispositivi in modo sincrono e assegnarli al tempo. Quindi utilizzo mpstat -P ALL 1 per verificare se i singoli core stanno funzionando in modo insolito. wa che impedisce di interpretare in modo errato i valori medi. Se ci sono indizi di una causa, utilizzo pidstat -d o iotop per vedere esattamente quale PID sta utilizzando il maggior numero di condivisioni di I/O. Negli ambienti di hosting con database, per prima cosa distinguo i picchi di lettura da quelli di scrittura, poiché le strategie di write-back e i modelli di fsync generano sintomi molto diversi e possono quindi essere utilizzati per un monitoraggio mirato. Misure lo rendono possibile. Per domande più approfondite sullo storage, una panoramica come quella che si trova su Collo di bottiglia I/O nell'hosting, prima di modificare il kernel o il file system.
Chiara demarcazione tra virtualizzazione e container
Nelle macchine virtuali considero wa insieme a st (Steal) e misurare in aggiunta sull'hypervisor, perché solo lì i dispositivi reali e Spunti sono visibili. Le aggregazioni di storage (thin provisioning, dedupe, snapshot) spostano i picchi di latenza verso il basso nello stack, con il seguente effetto sulla VM attendere salta, mentre %util rimane poco appariscente. Nei contenitori limito o disaccoppio I/O con le regole del Cgroup (ad esempio, limiti di IOPS/throughput) al fine di Vicini rumorosi per domarli. Documento i limiti per ogni servizio, in modo che i valori misurati siano riproducibili e gli allarmi mantengano il loro contesto. Importante: un alto wa nella macchina virtuale può essere innescato da backup, scrub o ricostruzioni a livello di host; io metto in relazione i tempi con i lavori dell'host prima di toccare l'applicazione.
Limiti, soglie e passi successivi
Uso alcune soglie chiare per decidere se c'è un vero collo di bottiglia e quali azioni intraprendere per stabilizzare sensibilmente le prestazioni. Tengo conto del tipo di supporto, del carico di lavoro e dei requisiti di latenza, perché le stesse cifre su HDD e NVMe hanno implicazioni diverse. Uso la seguente tabella come guida rapida da utilizzare nei miei playbook. Misuro più volte nell'arco di minuti e sotto carico, in modo che i valori anomali non generino falsi allarmi e sia possibile riconoscere le tendenze. La uso come base per un'azione mirata, invece di sostituire di riflesso l'hardware o il sistema. Parametri massicciamente.
| Metriche | Soglia | Interpretazione | Le prossime tappe |
|---|---|---|---|
| wa (vmstat) | > 15-20% | Tempo di attesa I/O significativo | Controllare iostat; trovare la causa con pidstat/iotop; analizzare la cache e le scritture |
| %utile (iostat) | > 80-90% | Dispositivo utilizzato | correlare await/avgqu-sz; controllare la profondità della coda, lo scheduler, RAID e SSD/NVMe |
| attendere (ms) | > 10-20 ms SSD, > 30-50 ms HDD | Aumento della latenza | Distinguere tra casuale e sequenziale; personalizzare le opzioni del file system, il writeback, il journaling |
| avgqu-sz | > 1-2 persistente | La coda cresce | Limitare/aumentare il parallelismo; ottimizzare il modello di I/O dell'applicazione; controllare i limiti del controller. |
| si/so (vmstat) | > 0 sotto carico | Collo di bottiglia dello storage | Aumento della RAM; messa a punto di query e cache; controllo dei limiti di swappiness e di memoria. |
Cause nello stack: DB, file system, virtualizzazione
Con i database, spesso vedo join non indicizzati, buffer troppo piccoli e chiamate di fsync eccessive, mentre l'effettiva Cause per valori di attesa elevati. Controllo i piani di query, attivo i log per le dichiarazioni lente e regolo in modo oggettivo le dimensioni del pool di buffer InnoDB, le dimensioni dei file di log e i file aperti. A livello di file system, esamino le opzioni di montaggio, le modalità di journal e l'allineamento alla striscia RAID, perché le combinazioni sbagliate fanno esplodere i tempi di attesa. Nelle configurazioni virtualizzate, non mi affido solo alle misurazioni nella macchina virtuale, ma guardo all'host, perché è qui che si trovano i dispositivi a blocchi reali e i file aperti. Spunti diventano visibili. Questo mi permette di separare chiaramente gli effetti della deduplicazione, del thin provisioning o delle macchine virtuali vicine dai modelli di applicazione.
File system e opzioni di montaggio in dettaglio
Valuto i file system alla luce del carico di lavoro: ext4 in modalità ordinata o writeback minimizza le barriere all'intensità di scrittura, mentre XFS Il sistema è stato concepito per i carichi di lavoro paralleli. Opzioni come noatime oppure relatime ridurre le scritture di metadati, pigrizia sposta gli aggiornamenti del timestamp al writeback in bundle. Per il journaling, controllo gli intervalli di commit (ad esempio commit=) e verifico se i flush forzati (barriere) sono esacerbati dalle politiche di cache del controller. Sui RAID faccio attenzione all'allineamento pulito alla striscia (Parted/FDISK con inizio da 1MiB), altrimenti attendere attraverso Read-Modify-Write anche con schemi presumibilmente sequenziali. Per i database, spesso utilizzo strategie di O_DIRECT o di log flush diretto, ma solo dopo aver effettuato delle misurazioni, perché la cache del file system può ridurre drasticamente il carico di lettura se l'insieme di lavoro vi rientra.
Messa a punto: dal kernel all'applicazione
Inizio con semplici vittorie, ad esempio l'indicizzazione delle query, la scrittura in batch e una configurazione sensata del pooling delle connessioni, prima di iniziare a livello di sistema. Per il writeback, regolo vm.dirty_background_ratio, vm.dirty_ratio e vm.dirty_expire_centisecs in modo controllato, affinché il sistema scriva in modo contiguo e generi meno blocchi senza intasare la memoria. Per i dispositivi a blocchi, controllo lo scheduler I/O, la profondità della coda e il read-ahead, perché questi parametri influenzano direttamente la latenza e il throughput. Sui controller RAID, metto a punto la dimensione dello stripe e la politica della cache, mentre su SSD/NVMe per il firmware, TRIM e impostazioni di overprovisioning coerenti. Dopo ogni modifica, verifico con vmstat e iostat per diversi minuti se l'attesa cala e %util rimane stabile prima di passare alla fase successiva.
Interruzioni, NUMA e affinità
Controllo il carico di IRQ e la topologia NUMA perché entrambi hanno un effetto notevole sulle latenze. NVMe-Lego gli interrupt alle CPU del dominio NUMA del controller tramite affinità, in modo che i percorsi dei dati rimangano brevi. Se la tempesta di IRQ è in corso su un core, vedo un livello elevato di sy e il resto delle CPU sembra inattivo; mpstat lo espone. Consento l'irqbalance solo se la distribuzione corrisponde all'hardware, altrimenti imposto affinità specifiche. Verifico anche se l'applicazione e il suo I/O nella stessa zona NUMA (posizione di archiviazione), perché gli accessi cross-socket causano tempi di attesa in attendere può essere mascherato.
Automatizzare e visualizzare le misure
Per essere sicuro di riconoscere le tendenze, automatizzo le misurazioni e integro iostat/vmstat negli strumenti di monitoraggio, che possono essere utilizzati per analizzare i dati storici. Dati salvare. Ho impostato gli allarmi in modo conservativo, ad esempio da wa > 15% su diversi intervalli, combinati con soglie per await e %util per evitare falsi allarmi. Per le schermate delle metriche complessive, utilizzo dashboard che accostano le metriche di CPU, storage, rete e app in modo che le correlazioni siano immediatamente visibili. Se avete bisogno di un'introduzione alle metriche, potete trovarle su Metriche del server contesto compatto per il lavoro quotidiano. Per me è importante avere un processo ripetibile: misurare, formulare un'ipotesi, apportare modifiche, misurare di nuovo e analizzare i risultati. Risultati documento.
Test di carico riproducibili con fio
Se non ho un carico reale o se voglio verificare delle ipotesi, uso un carico di breve durata. fio-Test. Simulo modelli rappresentativi (ad esempio, 4k di lettura casuale, 64k di scrittura sequenziale, profili misti 70/30) e vario iodepth, per impostare la finestra di sweet spot tra attendere e il throughput. Separo rigorosamente i percorsi di test dai dati di produzione e annoto le condizioni al contorno (file system, opzioni di montaggio, scheduler, profondità della coda) in modo da poter classificare correttamente i risultati. Dopo la messa a punto, gli stessi test vengono utilizzati come controllo di regressione; solo quando attendere e %utile in modo coerente, apporto modifiche alla superficie.
Riconoscere i modelli di errore: modelli tipici
Se osservo un wa elevato con un %utile contemporaneamente elevato e un avgqu-sz in aumento, tutto parla a favore della saturazione del Dispositivo, cioè limiti fisici reali. Valori elevati di await con %util moderato tendono a indicare peculiarità del controller o della cache, come barriere, write-through o flush sporadici. Valori di si/so in aumento insieme a cali nella cache indicano chiaramente una mancanza di RAM, che gonfia artificialmente l'I/O e aumenta i tempi di attesa. Se il disco rimane poco appariscente, ma l'applicazione incastra scritture grandi e pesanti dal punto di vista della sincronizzazione, sposto il lavoro sulla scrittura asincrona, sul pipelining o sulla scrittura di file di testo. Lotto-meccanismi. Nelle configurazioni NFS o di archiviazione di rete, verifico anche la latenza, l'MTU, le ritrasmissioni e la cache sul lato server, perché il tempo di rete è direttamente mascherato come latenza di I/O in questo caso.
NFS/iSCSI e archiviazione distribuita
All'indirizzo NFS e iSCSI, distinguo tra dispositivo e percorso di rete: iostat mostra solo ciò che vede il livello di blocco: riconosco anche le ritrasmissioni, le latenze e i problemi di finestra tramite le metriche di rete. Alto attendere con moderata %utile sul dispositivo di blocco virtuale è tipico quando la rete si blocca o la cache lato server si raffredda. Per NFS controllo le opzioni di montaggio (rsize/wsize, proto, sync/async) e il lato server (thread, politiche di esportazione, cache), per iSCSI i parametri di sessione e di coda. Pianifico le finestre di manutenzione per i lavori del server (scrub, rebuild, ribilanciamento) in modo che non saturino lo storage condiviso nei momenti di picco e quindi causino l'indisponibilità del server. wa su tutti i clienti.
Esempi pratici: tre brevi scenari
Blog cluster con suggerimenti per la scrittura
In prima serata, i commenti e l'invalidazione della cache aumentano, mentre await e avgqu-sz in iostat aumentano significativamente, mentre %util rimane a 95%. Aumento delicatamente i parametri di writeback, ottimizzo l'invalidazione della cache a livello di percorso e aumento il log buffer di InnoDB in modo che ci siano meno piccole scritture di sincronizzazione. In seguito, l'attesa diminuisce in modo misurabile, i valori di bo rimangono alti, ma wa diminuisce, riducendo immediatamente i tempi di risposta. Allo stesso tempo, sostituisco singoli HDD con SSD per il journal, alleviando ulteriormente il collo di bottiglia. Lo schema mostra come Lotto-Combinare scrittura e diario più veloce.
Acquista con picchi di lettura e indici di ricerca
Le promozioni generano un forte carico di lettura, la velocità di lettura aumenta, l'attesa rimane moderata, ma l'applicazione reagisce ancora con lentezza alla navigazione nei filtri. Riconosco molte query non bufferizzate senza indici adeguati che superano il set di lavoro della cache del file system. Con l'indicizzazione mirata e la riscrittura delle query, il tempo di risposta scende, i risultati sono più spesso nella cache e iostat conferma un MB_read inferiore a parità di throughput. Allo stesso tempo, aumento leggermente il read-ahead per servire le scansioni sequenziali in modo più efficiente, riducendo ulteriormente le latenze. Ecco come verifico che Leggi-I modelli portano di nuovo a visite alla cache.
Host della macchina virtuale con „Vicino rumoroso“
Nelle singole macchine virtuali, top mostra un wa elevato, ma iostat nella macchina virtuale vede solo dispositivi virtuali con un utilizzo fuorviante. Misuro anche sull'hypervisor, vedo dispositivi a blocchi reali saturi e identifico come causa una VM vicina con backup aggressivi. I limiti della larghezza di banda e le finestre di backup modificate stabilizzano l'attesa e %util in tutto l'host. Quindi misuro nuovamente nella macchina virtuale e sull'host per confermare e prevenire l'effetto su entrambi i lati. Questo conferma che il vero Dispositivi-Le metriche mostrano sempre la verità all'ospite.
Lista di controllo per il prossimo incidente
Avvio prima i registri e le misurazioni in modo da non perdere alcun segnale e mantengo in funzione vmstat 1 e iostat -x 1 per diversi minuti. Quindi correlo i picchi temporali con gli eventi delle applicazioni e i timer di sistema prima di individuare i singoli processi con pidstat -d e formulare ipotesi. Il passo successivo è il controllo della memoria, dello swap e della cache, in modo da evitare che la carenza di RAM venga erroneamente riconosciuta come un problema di memoria. Disco- appare il problema. Solo quando ho isolato la causa, modifico esattamente una cosa, registro l'impostazione e valuto l'effetto su await, %util e wa. In questo modo, mantengo l'analisi riproducibile, imparo da ogni incidente e riduco il tempo che manca alla risoluzione del problema. Soluzione chiaramente.
Frequenti interpretazioni errate e inciampi
Non mi lascio ingannare da picchi isolati: Singoli secondi con alti wa sono normali, solo i plateau persistenti indicano un collo di bottiglia strutturale. %utile vicino a 100% è critico solo se attendere si alza contemporaneamente, altrimenti il dispositivo è semplicemente occupato. Su SSD/NVMe è una misura più elevata avgqu-sz Spesso è intenzionale, per sfruttare il parallelismo interno; mi limito a ridurre la frequenza solo quando non si raggiungono gli obiettivi di latenza. Controllo la scalatura della frequenza della CPU: un risparmio energetico aggressivo può aumentare i tempi di risposta e così wa sembrano peggiorare. E separo il TTFB delle applicazioni dalla latenza dello storage: la rete, gli handshake TLS e i servizi upstream possono produrre sintomi simili senza iostat „è “colpevole".
Breve riassunto per gli amministratori
L'analisi dell'attesa I/O con iostat e vmstat funziona rapidamente se leggo wa, await, %util e avgqu-sz insieme e li metto in relazione con il contesto del carico di lavoro. Per prima cosa identifico se c'è una reale saturazione del dispositivo o se sono i modelli di memoria e di app a determinare la latenza, e quindi seleziono la leva appropriata. Piccoli aggiustamenti mirati alle query, ai parametri di writeback, agli scheduler o alla profondità delle code hanno spesso il massimo effetto prima che siano necessarie costose modifiche hardware. Misurazione, ipotesi, modifica e rimisurazione rimangono la mia sequenza fissa, in modo che le decisioni rimangano comprensibili e ripetibili. È così che mantengo Linux-Il server è reattivo e garantisce una qualità nettamente superiore. Tempi di risposta sotto carico.
