{"id":19334,"date":"2026-05-14T12:39:05","date_gmt":"2026-05-14T10:39:05","guid":{"rendered":"https:\/\/webhosting.de\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/"},"modified":"2026-05-14T12:39:05","modified_gmt":"2026-05-14T10:39:05","slug":"server-io-aspettare-analizzare-iostat-vmstat-metriche-disco","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/","title":{"rendered":"Analisi dell'attesa I\/O del server con iostat e vmstat: ottimizzazione delle metriche dei server Linux"},"content":{"rendered":"<p>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. <strong>I\/O<\/strong> e <strong>CPU<\/strong> in.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>iostat<\/strong> e <strong>vmstat<\/strong> forniscono una visione complementare del carico della CPU e dello storage.<\/li>\n  <li><strong>wa<\/strong> tramite 15-20% e <strong>%utile<\/strong> via 80% mostrano un collo di bottiglia I\/O.<\/li>\n  <li><strong>attendere<\/strong> e <strong>avgqu-sz<\/strong> spiegare la latenza e le code.<\/li>\n  <li><strong>mpstat<\/strong> rileva un carico distribuito in modo non uniforme tra i core della CPU.<\/li>\n  <li><strong>Sintonizzazione<\/strong> varia da <strong>MySQL<\/strong> ai parametri e alla memoria del kernel.<\/li>\n<\/ul>\n\n<h2>Cosa si intende per attesa di I\/O sui server Linux?<\/h2>\n<p>In caso di attesa I\/O, la CPU attende in modo inattivo perch\u00e9 \u00e8 in attesa di dispositivi di memoria o di rete pi\u00f9 lenti, il che \u00e8 noto come <strong>wa<\/strong>-in strumenti come top o vmstat. Valuto questa percentuale come il tempo in cui i thread si bloccano e le richieste vengono completate pi\u00f9 tardi, cosa che gli utenti percepiscono direttamente come lentezza. Valori superiori a 10-20% spesso indicano un utilizzo completo del sistema <strong>Immagazzinamento<\/strong>-sottosistema, ad esempio quando HDD, array RAID o mount NFS sono utilizzati al massimo della loro capacit\u00e0. Nelle configurazioni di hosting con database, le query non indicizzate e i picchi di scrittura comportano inutili tempi di attesa sul sistema. <strong>Disco<\/strong>. Se volete ripassare i concetti, potete trovare le nozioni di base su <a href=\"https:\/\/webhosting.de\/it\/io-wait-comprendere-memoria-congestione-risolvere-ottimizzazione\/\">Comprendere l'I\/O Wait<\/a>, prima di andare all'allenamento.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/linux-server-io-8592.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Avvio rapido: leggere correttamente vmstat<\/h2>\n<p>Con vmstat, posso controllare i pi\u00f9 importanti <strong>Linux<\/strong>-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 \u00e8 che si tratti di puro <strong>Immagazzinamento<\/strong>-limite. Negli host multicore, combino vmstat con mpstat -P ALL 1, perch\u00e9 l'attesa dell'I\/O spesso riguarda solo singoli core e quindi in media appare pi\u00f9 innocua di quanto non sia in realt\u00e0.<\/p>\n\n<h2>Immagine fine della CPU: us\/sy\/st, coda di esecuzione e commutazione di contesto<\/h2>\n<p>Con vmstat e mpstat leggo pi\u00f9 di quanto non faccia solo <strong>wa<\/strong>: Alto <strong>noi<\/strong>Il lavoro applicativo \"pesante\" \u00e8 illustrato nelle sezioni seguenti, <strong>sy<\/strong> indica il lavoro del kernel\/driver, ad esempio con l'uso intensivo di <strong>I\/O<\/strong>. Negli ambienti virtualizzati faccio attenzione a <strong>st<\/strong> (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 (<strong>r<\/strong> in vmstat) con il numero di CPU: un r permanentemente pi\u00f9 alto del numero di CPU indica una congestione della CPU, non della rete. <strong>Immagazzinamento<\/strong>. Molti cambiamenti di contesto (<strong>cs<\/strong>) in combinazione con piccole scritture sincrone sono un indicatore di modelli di I\/O chiacchieroni. In questo modo evito di interpretare erroneamente la scarsit\u00e0 di CPU come un problema di I\/O.<\/p>\n\n<h2>Conoscere iostat in modo approfondito: metriche importanti<\/h2>\n<p>iostat -x 1 mi d\u00e0 l'estensione <strong>Disco<\/strong>-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. <strong>Piatto<\/strong> 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/linuxserveroptiokoni7553.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NVMe, SATA e RAID: il significato di %util, await e queue depth<\/h2>\n<p>Faccio una distinzione rigorosa tra i tipi di media: <strong>HDD<\/strong> mostra un livello pi\u00f9 alto <strong>attendere<\/strong>-anche con un indizio moderato, perch\u00e9 i movimenti della testa dominano. <strong>SSD<\/strong>\/NVMe scalano bene con il parallelismo, ed \u00e8 per questo che un valore pi\u00f9 alto di <strong>avgqu-sz<\/strong> pu\u00f2 essere normale, purch\u00e9 <strong>attendere<\/strong> rimane entro i limiti. Su NVMe con code multiple di invio\/completamento, leggo %util con pi\u00f9 cautela: i singoli dispositivi possono essere al limite gi\u00e0 a 60-70% se l'applicazione non genera sufficiente parallelismo o la profondit\u00e0 della coda (<strong>nr_richieste<\/strong>, <strong>profondit\u00e0_coda<\/strong>) \u00e8 troppo piccolo. Nella <strong>RAID<\/strong> Verifico se la dispersione dell'I\/O casuale incontra dimensioni di stripe troppo piccole; quindi <strong>attendere<\/strong> e <strong>%utile<\/strong> 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\u00f9 elevate per le scritture, ma le compenso con finestre di writeback pi\u00f9 ampie o con il batching lato app.<\/p>\n\n<h2>Flusso di lavoro diagnostico per lunghi tempi di attesa<\/h2>\n<p>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. <strong>wa<\/strong> 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\u00e9 le strategie di write-back e i modelli di fsync generano sintomi molto diversi e possono quindi essere utilizzati per un monitoraggio mirato. <strong>Misure<\/strong> lo rendono possibile. Per domande pi\u00f9 approfondite sullo storage, una panoramica come quella che si trova su <a href=\"https:\/\/webhosting.de\/it\/io-collo-di-bottiglia-hosting-analisi-della-latenza-ottimizzazione-dello-storage\/\">Collo di bottiglia I\/O nell'hosting<\/a>, prima di modificare il kernel o il file system.<\/p>\n\n<h2>Chiara demarcazione tra virtualizzazione e container<\/h2>\n<p>Nelle macchine virtuali considero <strong>wa<\/strong> insieme a <strong>st<\/strong> (Steal) e misurare in aggiunta sull'hypervisor, perch\u00e9 solo l\u00ec i dispositivi reali e <strong>Spunti<\/strong> 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 <strong>attendere<\/strong> salta, mentre %util rimane poco appariscente. Nei contenitori limito o disaccoppio <strong>I\/O<\/strong> con le regole del Cgroup (ad esempio, limiti di IOPS\/throughput) al fine di <strong>Vicini rumorosi<\/strong> 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 <strong>wa<\/strong> nella macchina virtuale pu\u00f2 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.<\/p>\n\n<h2>Limiti, soglie e passi successivi<\/h2>\n<p>Uso alcune soglie chiare per decidere se c'\u00e8 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\u00e9 le stesse cifre su HDD e NVMe hanno implicazioni diverse. Uso la seguente tabella come guida rapida da utilizzare nei miei playbook. Misuro pi\u00f9 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. <strong>Parametri<\/strong> massicciamente.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Metriche<\/th>\n      <th>Soglia<\/th>\n      <th>Interpretazione<\/th>\n      <th>Le prossime tappe<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>wa<\/strong> (vmstat)<\/td>\n      <td>&gt; 15-20%<\/td>\n      <td>Tempo di attesa I\/O significativo<\/td>\n      <td>Controllare iostat; trovare la causa con pidstat\/iotop; analizzare la cache e le scritture<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>%utile<\/strong> (iostat)<\/td>\n      <td>&gt; 80-90%<\/td>\n      <td>Dispositivo utilizzato<\/td>\n      <td>correlare await\/avgqu-sz; controllare la profondit\u00e0 della coda, lo scheduler, RAID e SSD\/NVMe<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>attendere<\/strong> (ms)<\/td>\n      <td>&gt; 10-20 ms SSD, &gt; 30-50 ms HDD<\/td>\n      <td>Aumento della latenza<\/td>\n      <td>Distinguere tra casuale e sequenziale; personalizzare le opzioni del file system, il writeback, il journaling<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>avgqu-sz<\/strong><\/td>\n      <td>&gt; 1-2 persistente<\/td>\n      <td>La coda cresce<\/td>\n      <td>Limitare\/aumentare il parallelismo; ottimizzare il modello di I\/O dell'applicazione; controllare i limiti del controller.<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>si\/so<\/strong> (vmstat)<\/td>\n      <td>&gt; 0 sotto carico<\/td>\n      <td>Collo di bottiglia dello storage<\/td>\n      <td>Aumento della RAM; messa a punto di query e cache; controllo dei limiti di swappiness e di memoria.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server-metrics-optimization-8421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cause nello stack: DB, file system, virtualizzazione<\/h2>\n<p>Con i database, spesso vedo join non indicizzati, buffer troppo piccoli e chiamate di fsync eccessive, mentre l'effettiva <strong>Cause<\/strong> 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\u00e0 di journal e l'allineamento alla striscia RAID, perch\u00e9 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\u00e9 \u00e8 qui che si trovano i dispositivi a blocchi reali e i file aperti. <strong>Spunti<\/strong> diventano visibili. Questo mi permette di separare chiaramente gli effetti della deduplicazione, del thin provisioning o delle macchine virtuali vicine dai modelli di applicazione.<\/p>\n\n<h2>File system e opzioni di montaggio in dettaglio<\/h2>\n<p>Valuto i file system alla luce del carico di lavoro: <strong>ext4<\/strong> in modalit\u00e0 ordinata o writeback minimizza le barriere all'intensit\u00e0 di scrittura, mentre <strong>XFS<\/strong> Il sistema \u00e8 stato concepito per i carichi di lavoro paralleli. Opzioni come <strong>noatime<\/strong> oppure <strong>relatime<\/strong> ridurre le scritture di metadati, <strong>pigrizia<\/strong> 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 <strong>attendere<\/strong> 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\u00e9 la cache del file system pu\u00f2 ridurre drasticamente il carico di lettura se l'insieme di lavoro vi rientra.<\/p>\n\n<h2>Messa a punto: dal kernel all'applicazione<\/h2>\n<p>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\u00e9 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\u00e0 della coda e il read-ahead, perch\u00e9 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 <strong>SSD<\/strong>\/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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/TechOfficeServerAnalyse4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interruzioni, NUMA e affinit\u00e0<\/h2>\n<p>Controllo il carico di IRQ e la topologia NUMA perch\u00e9 entrambi hanno un effetto notevole sulle latenze. <strong>NVMe<\/strong>-Lego gli interrupt alle CPU del dominio NUMA del controller tramite affinit\u00e0, in modo che i percorsi dei dati rimangano brevi. Se la tempesta di IRQ \u00e8 in corso su un core, vedo un livello elevato di <strong>sy<\/strong> e il resto delle CPU sembra inattivo; <strong>mpstat<\/strong> lo espone. Consento l'irqbalance solo se la distribuzione corrisponde all'hardware, altrimenti imposto affinit\u00e0 specifiche. Verifico anche se l'applicazione e il suo <strong>I\/O<\/strong> nella stessa zona NUMA (posizione di archiviazione), perch\u00e9 gli accessi cross-socket causano tempi di attesa in <strong>attendere<\/strong> pu\u00f2 essere mascherato.<\/p>\n\n<h2>Automatizzare e visualizzare le misure<\/h2>\n<p>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. <strong>Dati<\/strong> salvare. Ho impostato gli allarmi in modo conservativo, ad esempio da wa &gt; 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 <a href=\"https:\/\/webhosting.de\/it\/metriche-del-server-cpu-carico-inattivo-attesa-analizzare-serverboost\/\">Metriche del server<\/a> contesto compatto per il lavoro quotidiano. Per me \u00e8 importante avere un processo ripetibile: misurare, formulare un'ipotesi, apportare modifiche, misurare di nuovo e analizzare i risultati. <strong>Risultati<\/strong> documento.<\/p>\n\n<h2>Test di carico riproducibili con fio<\/h2>\n<p>Se non ho un carico reale o se voglio verificare delle ipotesi, uso un carico di breve durata. <strong>fio<\/strong>-Test. Simulo modelli rappresentativi (ad esempio, 4k di lettura casuale, 64k di scrittura sequenziale, profili misti 70\/30) e vario <strong>iodepth<\/strong>, per impostare la finestra di sweet spot tra <strong>attendere<\/strong> 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\u00e0 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 <strong>attendere<\/strong> e <strong>%utile<\/strong> in modo coerente, apporto modifiche alla superficie.<\/p>\n\n<h2>Riconoscere i modelli di errore: modelli tipici<\/h2>\n<p>Se osservo un wa elevato con un %utile contemporaneamente elevato e un avgqu-sz in aumento, tutto parla a favore della saturazione del <strong>Dispositivo<\/strong>, cio\u00e8 limiti fisici reali. Valori elevati di await con %util moderato tendono a indicare peculiarit\u00e0 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. <strong>Lotto<\/strong>-meccanismi. Nelle configurazioni NFS o di archiviazione di rete, verifico anche la latenza, l'MTU, le ritrasmissioni e la cache sul lato server, perch\u00e9 il tempo di rete \u00e8 direttamente mascherato come latenza di I\/O in questo caso.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server_metrics_analysis_1423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS\/iSCSI e archiviazione distribuita<\/h2>\n<p>All'indirizzo <strong>NFS<\/strong> e iSCSI, distinguo tra dispositivo e percorso di rete: <strong>iostat<\/strong> mostra solo ci\u00f2 che vede il livello di blocco: riconosco anche le ritrasmissioni, le latenze e i problemi di finestra tramite le metriche di rete. Alto <strong>attendere<\/strong> con moderata <strong>%utile<\/strong> sul dispositivo di blocco virtuale \u00e8 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\u00e0 del server. <strong>wa<\/strong> su tutti i clienti.<\/p>\n\n<h2>Esempi pratici: tre brevi scenari<\/h2>\n<h3>Blog cluster con suggerimenti per la scrittura<\/h3>\n<p>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 <strong>Lotto<\/strong>-Combinare scrittura e diario pi\u00f9 veloce.<\/p>\n<h3>Acquista con picchi di lettura e indici di ricerca<\/h3>\n<p>Le promozioni generano un forte carico di lettura, la velocit\u00e0 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\u00f9 spesso nella cache e iostat conferma un MB_read inferiore a parit\u00e0 di throughput. Allo stesso tempo, aumento leggermente il read-ahead per servire le scansioni sequenziali in modo pi\u00f9 efficiente, riducendo ulteriormente le latenze. Ecco come verifico che <strong>Leggi<\/strong>-I modelli portano di nuovo a visite alla cache.<\/p>\n<h3>Host della macchina virtuale con \u201eVicino rumoroso\u201c<\/h3>\n<p>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 <strong>Dispositivi<\/strong>-Le metriche mostrano sempre la verit\u00e0 all'ospite.<\/p>\n\n<h2>Lista di controllo per il prossimo incidente<\/h2>\n<p>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 \u00e8 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. <strong>Disco<\/strong>- 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. <strong>Soluzione<\/strong> chiaramente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/serveranalyse-linuxmetrics-4581.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Frequenti interpretazioni errate e inciampi<\/h2>\n<p>Non mi lascio ingannare da picchi isolati: Singoli secondi con alti <strong>wa<\/strong> sono normali, solo i plateau persistenti indicano un collo di bottiglia strutturale. <strong>%utile<\/strong> vicino a 100% \u00e8 critico solo se <strong>attendere<\/strong> si alza contemporaneamente, altrimenti il dispositivo \u00e8 semplicemente occupato. Su <strong>SSD<\/strong>\/NVMe \u00e8 una misura pi\u00f9 elevata <strong>avgqu-sz<\/strong> Spesso \u00e8 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\u00f2 aumentare i tempi di risposta e cos\u00ec <strong>wa<\/strong> 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 <strong>iostat<\/strong> \u201e\u00e8 \u201ccolpevole\".<\/p>\n\n<h2>Breve riassunto per gli amministratori<\/h2>\n<p>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'\u00e8 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\u00e0 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. \u00c8 cos\u00ec che mantengo <strong>Linux<\/strong>-Il server \u00e8 reattivo e garantisce una qualit\u00e0 nettamente superiore. <strong>Tempi di risposta<\/strong> sotto carico.<\/p>","protected":false},"excerpt":{"rendered":"<p>Analisi dell'attesa I\/O del server con iostat e vmstat: ottimizzare le metriche del server Linux per ottenere le massime prestazioni nell'hosting.<\/p>","protected":false},"author":1,"featured_media":19327,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-19334","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"61","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"I\/O Wait Analyse","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19327","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=19334"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19334\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/19327"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=19334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=19334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=19334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}