{"id":21483,"date":"2026-09-17T11:51:02","date_gmt":"2026-09-17T09:51:02","guid":{"rendered":"https:\/\/webhosting.de\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/"},"modified":"2026-09-17T11:51:02","modified_gmt":"2026-09-17T09:51:02","slug":"interpretare-correttamente-vmstat-su-linux-analisi-delle-prestazioni-e-monitoraggio","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/","title":{"rendered":"Interpretare correttamente vmstat su Linux per un'analisi efficace delle prestazioni"},"content":{"rendered":"<p>Ti mostrer\u00f2 come interpretare vmstat su Linux in modo mirato: potrai individuare colli di bottiglia della CPU, pressione sulla memoria, swap e tempi di attesa I\/O in pochi secondi. Ecco come interpretare con sicurezza le colonne r, b, free, si\/so, bi\/bo e us\/sy\/id\/wa\/st e dedurre misure concrete dai modelli osservati \u2013 senza tirare a indovinare, con <strong>chiaro<\/strong> Regole.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Coda di esecuzione<\/strong> vs. Blocchi: r indica il carico della CPU, b segnala tempi di attesa I\/O.<\/li>\n  <li><strong>Memoria<\/strong> Valutazione realistica: la gratuit\u00e0 da sola non conta, \u00e8 il \u00absi\/so\u00bb a fare la differenza.<\/li>\n  <li><strong>I\/O<\/strong> In sintesi: bi\/bo non destano preoccupazioni se il valore rimane basso.<\/li>\n  <li><strong>Quote di mercato delle CPU<\/strong> Significato: us+sy alto, id basso \u2192 carico elevato.<\/li>\n  <li><strong>Linee di base<\/strong> Creare: confrontare i valori della vita quotidiana con le fasi problematiche.<\/li>\n<\/ul>\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\/09\/linux-vmstat-analyse-9847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cosa mostra realmente vmstat?<\/h2>\n\n<p>Vmstat raggruppa lo stato dei processi, la memoria, lo swap, l\u2019I\/O a blocchi e le quote di utilizzo della CPU in un output sintetico che in pochi secondi fornisce un <strong>a livello di sistema<\/strong> Fornisce un\u2019idea generale. Per prima cosa leggo \u201eprocs\u201c per r\/b, poi \u201ememory\/swap\u201c per free, buff, cache e si\/so. Successivamente controllo \u201eio\u201c con bi\/bo e concludo con \u201ecpu\u201c per us, sy, id, wa e, facoltativamente, st. Questa sequenza mi aiuta a distinguere causa ed effetto: un valore elevato di r indica carico di calcolo, un valore elevato di b indica tempi di attesa I\/O, mentre wa collega l\u2019inattivit\u00e0 della CPU alla latenza I\/O. In questo modo capisco se il collo di bottiglia \u00e8 il carico di calcolo, la carenza di memoria o il supporto di dati \u2013 e mi risparmio <strong>Deviazioni<\/strong>.<\/p>\n\n<h2>Inizio tra 60 secondi: chiamate e intervalli<\/h2>\n\n<p>Per ottenere un\u2019istantanea a partire dall\u2019avvio del sistema, eseguo il comando \u201evmstat\u201c senza parametri; per analisi pi\u00f9 approfondite utilizzo \u201evmstat 1\u201c oppure \u201evmstat 5 12\u201c per ottenere dodici punti di misurazione ogni cinque secondi e ottengo un <strong>temporale<\/strong> Riga. Importante: la prima riga riporta i valori medi dal riavvio del sistema, pertanto valuto soprattutto le righe successive. Con Delay\/Count controllo la frequenza di campionamento e la durata, ad esempio \u201evmstat 1 30\u201c in caso di picchi brevi. Per carichi di lavoro instabili imposto 1\u20132 secondi, mentre per scenari tranquilli preferisco 5 secondi. Osservo le tendenze, non i singoli fotogrammi, perch\u00e9 sono gli schemi a rivelare le vere <strong>Cause<\/strong> spettacolo.<\/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\/09\/vmstat_performance_4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Leggere i processi: r e b nella vita di tutti i giorni<\/h2>\n\n<p>La colonna r mostra i thread pronti all'esecuzione che sono in attesa di tempo CPU, mentre b conta i thread bloccati, spesso in attesa di I\/O. Se r rimane nettamente superiore al numero di core fisici, si impone un <strong>Colli di bottiglia della CPU<\/strong> ; su quattro core, un valore r=8 mantenuto per un periodo prolungato \u00e8 considerato un chiaro segnale. Un valore b maggiore di 0 mantenuto per un periodo prolungato indica supporti di dati lenti, database sovraccarichi o percorsi di rete o di archiviazione lenti. Correlando r con us+sy e id: se id \u00e8 basso e r \u00e8 alto, la CPU \u00e8 sotto sforzo; se wa \u00e8 alto e b \u00e8 alto, \u00e8 l\u2019I\/O a rallentare il sistema. In questo modo decido se scalare la potenza di calcolo, ottimizzare le query o il <strong>Sistema di stoccaggio<\/strong> controllo.<\/p>\n\n<h2>Interpretazione delle memorie: free, buff, cache, swpd<\/h2>\n\n<p>Un valore basso di \"free\" \u00e8 normale su Linux, poich\u00e9 il kernel utilizza in modo intensivo la RAM come cache, il che accelera l'accesso ai file e garantisce un vero <strong>Produttivit\u00e0<\/strong> porta. Per questo motivo prendo pi\u00f9 in considerazione swpd e gli stream di swap si\/so piuttosto che solo free. Un valore elevato di cache va bene, purch\u00e9 si\/so rimanga quasi sempre a 0; solo un movimento persistente dello swap indica una pressione reale. Se si verificano anche latenza o addirittura OOM, intervengo: aumento la RAM, ottimizzo i processi per tempo o regolo le dimensioni della cache e della JVM. Il contesto rimane importante: il carico di lavoro, la dimensione della memoria e il layout NUMA determinano ci\u00f2 che nel tuo ambiente \u00e8 considerato <strong>sano<\/strong> vale.<\/p>\n\n<h2>Attivit\u00e0 di swap: classificare in entrambi i casi<\/h2>\n\n<p>Le colonne \"si\/so\" misurano il flusso costante di dati tra la RAM e lo swap in KB\/s e mettono in evidenza il carico effettivo sulla memoria, non solo quello percepito <strong>carenza<\/strong>. Brevi picchi sono normali, ad esempio quando vengono spostate pagine utilizzate raramente. La situazione diventa critica quando questi valori rimangono costantemente superiori a 0; ci\u00f2 rallenta tutto, poich\u00e9 ogni operazione di paging genera costi aggiuntivi di I\/O. Valori elevati di \u00abso\u00bb indicano uno spostamento attivo in memoria di paging e i tempi di risposta aumentano in modo significativo. A questo punto intervengo sulle cause: riduco il consumo di memoria, espando la RAM o ottimizzo i servizi che richiedono molta memoria <strong>sintonia<\/strong>.<\/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\/09\/vmstat-linux-performance-analysis-6234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendere l'I\/O a blocchi: bi e bo<\/h2>\n\n<p>Con bi\/bo rilevo la velocit\u00e0 di lettura e scrittura in blocchi al secondo, ma senza contesto non la valuto; ci\u00f2 che conta \u00e8 l'interazione con <strong>wa<\/strong>. Valori elevati di bi\/bo, accompagnati da un valore wa altrettanto elevato, indicano che lo storage non riesce a tenere il passo. Se un valore bi elevato si verifica in un database, controllo i profili delle query e gli hit della cache prima di sostituire l\u2019hardware. Per un'analisi pi\u00f9 approfondita dei tempi, utilizzo iostat e analizzo la lunghezza delle code e le latenze, in modo da poter <a href=\"https:\/\/webhosting.de\/it\/server-io-aspettare-analizzare-iostat-vmstat-metriche-disco\/\">Analisi dell\u2019attesa I\/O<\/a> e affrontare in modo mirato le carenze. Solo se wa rimane basso, ma bi\/bo sale alle stelle in modo duraturo, penso a <strong>Scala<\/strong> del sistema di archiviazione.<\/p>\n\n<h2>Quote della CPU: us, sy, id, wa, st<\/h2>\n\n<p>Valori US elevati con WA basso indicano un lavoro utile produttivo, mentre valori SY elevati indicano un elevato overhead del kernel, come innumerevoli piccole operazioni di I\/O o molte <strong>Cambiamento di contesto<\/strong>. Se id scende vicino a 0 e rimane tale, la CPU sta funzionando al limite; se a questo si aggiunge un valore elevato di r, ci\u00f2 indica un carico di calcolo elevato. Se wa aumenta, la CPU \u00e8 in attesa di operazioni I\/O: in questo caso, l\u2019ottimizzazione dello storage spesso porta a risultati migliori rispetto agli aggiornamenti della CPU. Nelle VM prendo in considerazione st (steal): valori elevati di st indicano che l\u2019hypervisor sottrae tempo di CPU, quindi ne parlo con l\u2019amministratore in merito al carico dell\u2019host. Valuto sempre us+sy come somma, poich\u00e9 questa mostra l\u2019attivit\u00e0 <strong>Lavoro<\/strong> nel sistema.<\/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\/09\/vmstat_linux_perf_Bild_7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Guida rapida: colonne e valori di riferimento<\/h2>\n\n<p>Utilizzo la tabella seguente come breve promemoria quando analizzo i risultati di vmstat per una prima <strong>Valutazione<\/strong> lettura trasversale.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Colonna<\/th>\n      <th>Significato<\/th>\n      <th>A cosa faccio attenzione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>r<\/td>\n      <td>Thread pronti per l'esecuzione<\/td>\n      <td>Permanente &gt; Nuclei \u2192 <strong>Pressione della CPU<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>b<\/td>\n      <td>Discussioni bloccate<\/td>\n      <td>Costante &gt; 0 + wa al potere \u2192 problema di I\/O<\/td>\n    <\/tr>\n    <tr>\n      <td>libero<\/td>\n      <td>RAM gratuita<\/td>\n      <td>Un valore basso va bene, purch\u00e9 si\/so rimanga \u2248 0<\/td>\n    <\/tr>\n    <tr>\n      <td>buff\/cache<\/td>\n      <td>Buffer FS\/Cache di pagina<\/td>\n      <td>Avere molta cache \u00e8 positivo; pu\u00f2 essere condiviso <strong>diventare<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>si\/so<\/td>\n      <td>Swap In\/Out<\/td>\n      <td>Costante &gt; 0 \u2192 pressione effettiva nel serbatoio<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo<\/td>\n      <td>I\/O a blocchi<\/td>\n      <td>\u00c8 critico solo se wa \u00e8 contemporaneamente elevato<\/td>\n    <\/tr>\n    <tr>\n      <td>us\/sy<\/td>\n      <td>Utente\/Kernel<\/td>\n      <td>us+sy costante &gt; 80% \u2192 alto <strong>Carico<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>id<\/td>\n      <td>marcia a vuoto<\/td>\n      <td>Valore vicino a 0 nel tempo \u2192 CPU satura<\/td>\n    <\/tr>\n    <tr>\n      <td>wa<\/td>\n      <td>Attesa I\/O<\/td>\n      <td>Alto con b alto \u2192 Causa: lo storage<\/td>\n    <\/tr>\n    <tr>\n      <td>st<\/td>\n      <td>Steal (macchine virtuali)<\/td>\n      <td>Alto \u2192 L'hypervisor utilizza <strong>CPU<\/strong>-Tempo<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Linee di base e monitoraggio continuo<\/h2>\n\n<p>Non mi baso su singoli dati isolati, ma confronto gli stessi valori con i valori di riferimento relativi a periodi tranquilli, in modo da poter individuare con precisione i valori anomali <strong>riconoscere<\/strong>. Il comando \u201evmstat 1 60\u201c mi fornisce un profilo di carico su un minuto, che confronto con le fasi normali note. Per avere una visione storica utilizzo <a href=\"https:\/\/webhosting.de\/it\/sar-sysstat-monitoraggio-server-linux\/\">Monitoraggio sar\/sysstat<\/a>, per valutare l'andamento nel corso dei giorni e affinare i valori limite. Impostiamo gli avvisi in modo prudente: r rispetto ai nuclei, si\/so diverso da 0 su pi\u00f9 intervalli, wa sensibilmente aumentato. In questo modo interveniamo tempestivamente, prima che gli utenti segnalino ritardi e prima che <strong>Picco<\/strong>- Le fasi si aggravano.<\/p>\n\n<h2>Vmstat in combinazione con altri strumenti<\/h2>\n\n<p>Comincio con vmstat, valuto la situazione in base agli andamenti e approfondisco in modo mirato con iostat, mpstat, pidstat o le metriche delle applicazioni, in modo da individuare le cause <strong>chiaro<\/strong> assegna. Mentre vmstat mostra i tempi di attesa I\/O, io misuro con iostat le latenze e le code per ciascun dispositivo. Se r indica un limite del kernel, mpstat evidenzia le asimmetrie del kernel. In caso di picchi di carico dei processi, fornisce <a href=\"https:\/\/webhosting.de\/it\/pidstat-linux-analisi-dei-processi-monitoraggio\/\">Analisi dei processi pidstat<\/a> i thread pi\u00f9 accesi sul tema del tempo. Solo la correlazione con i log e i tempi delle applicazioni rende il quadro pi\u00f9 chiaro e mi porta alla vera <strong>Causa<\/strong>.<\/p>\n\n<h2>Riconoscere gli schemi e agire<\/h2>\n\n<p>Se vedo che r \u00e8 alto, id basso e wa moderato, spesso l'applicazione ottimizza in modo troppo esigente in termini di calcolo, motivo per cui controllo il codice o il parallelismo e pianifico le risorse della CPU prima di <strong>Hardware<\/strong> Se i valori di b, wa e bi\/bo sono elevati, prendo in considerazione l\u2019ottimizzazione dello storage, l\u2019ottimizzazione delle query e il caching. Se il valore di free \u00e8 basso (con si\/so maggiore di 0), riduco il consumo di memoria, eseguo lo streaming dei risultati o aumento la RAM. Se i valori di us risultano moderati e quelli di sy molto elevati, controllo i filtri dei pacchetti, le opzioni del file system o i driver. Con questa lista di controllo agisco rapidamente e impiego il tempo dove \u00e8 pi\u00f9 <strong>conteggi<\/strong>.<\/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\/09\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come evitare errori di misurazione: campionamento, unit\u00e0 di misura, prima riga<\/h2>\n\n<p>Ho scelto di non considerare la prima riga per individuare anomalie acute, poich\u00e9 essa calcola la media sin dall\u2019avvio del sistema e appiana completamente i picchi. Inoltre, baso la frequenza di campionamento sull\u2019ipotesi causale: rilevo i picchi della CPU con intervalli di 1 secondo, mentre le perdite di memoria lente con intervalli di 5\u201310 secondi. Presto attenzione alle unit\u00e0 di misura: si\/so indicano KB\/s, bi\/bo \u201eblocchi\/s\u201c (storicamente 1 KB per blocco, variabile a seconda della versione di vmstat). Verifico se \u201evmstat -w\u201c (output esteso) evita il troncamento delle colonne e se i cambiamenti di frequenza di clock (P-States, Turbo) influenzano la percezione del carico a breve termine. Sincronizzo le misurazioni con i picchi dell\u2019applicazione, invece di considerare ciecamente \u201eminuti interi\u201c.<\/p>\n\n<h2>Decodifica della sezione \"System\": in e cs<\/h2>\n\n<p>Oltre a procs\/memory\/swap\/io\/cpu, vmstat mostra anche \u201esystem\u201c: <strong>in<\/strong> (interruzioni\/s) e <strong>cs<\/strong> (cambi di contesto al secondo). Questi due valori mi forniscono molte informazioni sull'overhead del kernel.<\/p>\n<ul>\n  <li>cs molto elevato a carico di lavoro moderato: flutter dei thread, batch dei worker troppo piccoli o contesa sui lock. Aumento le dimensioni dei batch, regolo il parallelismo (pool di thread) e verifico i punti critici dello scheduler e dei mutex.<\/li>\n  <li>a picchi improvvisi: ondate di interrupt di rete o di archiviazione, effetti NAPI\/polling o interrupt del timer. Effettuo un confronto con la percentuale sy e i risultati di iostat per verificare i driver o i percorsi di rete.<\/li>\n  <li>cs proporzionale a r: ci\u00f2 indica una pressione costante di cambiamento di contesto dovuta a un parallelismo eccessivo. Riduco il parallelismo attivo oppure assegno gli hot-thread ai core.<\/li>\n<\/ul>\n<p>Correlando sempre in\/cs con sy e b\/wa: solo nel loro insieme emerge un quadro chiaro che permette di capire se il lavoro del kernel \u00e8 utile (ad es. in termini di throughput) o se rappresenta un puro overhead.<\/p>\n\n<h2>Varianti e opzioni utili di vmstat<\/h2>\n\n<p>Utilizzo vmstat in modo flessibile per ottenere ulteriori punti di vista senza dover cambiare strumento:<\/p>\n<ul>\n  <li><strong>vmstat -s<\/strong>: Contatori cumulativi (ad es. processi avviati all'avvio del sistema, errori di pagina maggiori\/minori). Ideali per confrontare le perdite o il numero di casi in intervalli di tempo.<\/li>\n  <li><strong>vmstat -m<\/strong>: Utilizzo dello slab \u2013 aiuta a classificare le cache del kernel (Dentry\/Inode, rete) come consumatori di RAM.<\/li>\n  <li><strong>vmstat -d<\/strong>: Eventi relativi al disco a livello di totali. Non sostituisce iostat, ma \u00e8 utile per una rapida verifica della situazione reale.<\/li>\n  <li><strong>vmstat -S M<\/strong>: Convertire le unit\u00e0 (M\/K) per facilitare la lettura dei numeri.<\/li>\n  <li><strong>vmstat -w<\/strong>: Le colonne pi\u00f9 larghe evitano che le cifre vengano troncate nelle colonne di numeri molto lunghe.<\/li>\n<\/ul>\n<p>Abbino queste opzioni a brevi intervalli, in modo da non perdere nessun evento e mantenere comunque una visione d'insieme.<\/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\/09\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container, macchine virtuali e cgroup: caratteristiche particolari<\/h2>\n\n<p>Nei container interpreto vmstat con cautela: molti dati del kernel sono a livello di host, mentre i limiti provengono dai Cgroup. Valori elevati di r in un container riflettono la prospettiva del namespace, ma il tempo CPU effettivo pu\u00f2 essere limitato dalla quota CPU o dalle quote di CPU. Mi riferisco a <strong>st<\/strong> (Steal) nelle VM: un valore elevato di st significa che l\u2019hypervisor mi sottrae tempo \u2013 in tal caso, anche un\u2019ottimizzazione perfetta dell\u2019app serve a poco, fintanto che l\u2019host \u00e8 sovraccarico. In presenza di limiti di memoria nei Cgroup, il si\/so potrebbe non verificarsi, anche se il container \u201esi agita\u201c al limite (terminazioni OOM invece dello swap). Controllo quindi anche i log OOM e le statistiche dei Cgroup e confronto le immagini vmstat con i limiti.<\/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\/09\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA e affinit\u00e0: quando la localit\u00e0 fa la differenza<\/h2>\n\n<p>Sugli host NUMA controllo r e us\/sy per ogni core (con mpstat) e osservo se singoli socket si \u201esurriscaldano\u201c mentre altri rimangono inattivi. Una localizzazione della memoria inadeguata comporta un aumento di cs\/sy e b\/wa a causa di accessi alla memoria a distanza. Testo l\u2019affinit\u00e0 della CPU e della memoria (cpuset, numactl), imposto gli heap di grandi dimensioni in modalit\u00e0 \u201einterleaved\u201c o \u00abstrictly local\u00bb e mi assicuro che i thread \u00abcaldi\u00bb vengano eseguiti dove si trova il loro footprint di dati. Un layout NUMA stabile livella il cs, riduce i picchi di wa e aumenta la <strong>Pianificabilit\u00e0<\/strong> sotto carico.<\/p>\n\n<h2>Evitare interpretazioni errate: wa e b sono molto pi\u00f9 che semplici \u201esupporti di dati lenti\u201c<\/h2>\n\n<p>Il valore wa non aumenta solo a causa delle classiche latenze del disco: anche le reti NFS\/ad alta latenza, l\u2019object storage saturo, i volumi cloud che causano blocchi o i writeback lenti della cache di pagina fanno salire il valore wa. b conta i task in stato di sospensione non interrompibile (D-State) \u2013 tra questi rientrano anche i blocchi a livello di driver, percorsi di rete o blocchi del filesystem. Per questo motivo non valuto mai wa\/b isolatamente, ma sempre insieme a bi\/bo e ai tempi delle applicazioni. Se wa \u00e8 alto, ma bi\/bo \u00e8 basso, spesso si tratta di un <strong>Dipendenza dall'attesa<\/strong> al di l\u00e0 della mera questione della velocit\u00e0 di trasmissione dei dispositivi (ad es. locking, I\/O remoto, congestione del writeback).<\/p>\n\n<h2>Ottimizzazione con buon senso: Swappiness, Writeback, Scheduler<\/h2>\n\n<p>Modifico Kernel-Tuner solo dopo aver effettuato le misurazioni e con un piano di ripristino:<\/p>\n<ul>\n  <li><strong>vm.swappiness<\/strong>: Un valore basso riduce lo swapping proattivo, il che \u00e8 utile per le app in cui la latenza \u00e8 un fattore critico; se troppo basso, pu\u00f2 aumentare la pressione sulla cache di pagina.<\/li>\n  <li><strong>vm.dirty_background_ratio \/ vm.dirty_ratio<\/strong> (o *_bytes): influenzano i tempi di writeback. Valori troppo elevati causano lunghi picchi di scrittura (picchi di wa), mentre valori troppo bassi aumentano i piccoli flush costanti (sy\/bo in aumento).<\/li>\n  <li><strong>Scheduler I\/O\/Profondit\u00e0 della coda<\/strong>: Impostazioni Optima diverse su NVMe rispetto a HDD\/RAID. Prima di apportare modifiche, misuro i compromessi tra latenza e velocit\u00e0 di trasferimento con iostat.<\/li>\n  <li><strong>Percorsi di rete<\/strong>: Molti piccoli pacchetti\/interrupt affluiscono in \/cs\/sy. Le principali leve di ottimizzazione sono GRO\/LRO, RPS\/RFS, IRQ-Affinity: effettuo misurazioni prima e dopo.<\/li>\n<\/ul>\n<p>Il mio obiettivo \u00e8 ottenere andamenti stabili e prevedibili in vmstat: us\/sy pi\u00f9 stabili, wa\/b pi\u00f9 bassi, si\/so vicini a 0. Solo allora procedo all'ampliamento dell'hardware.<\/p>\n\n<h2>Playbook: analisi in 3 minuti con vmstat<\/h2>\n\n<ul>\n  <li>0:00\u20130:30 \u2013 \u201evmstat 1 30\u201c: ignorare la prima riga, quindi esaminare r\/b, us\/sy\/id\/wa. Domanda: limite della CPU (r alto, id basso) o limite I\/O (b\/wa alti)?<\/li>\n  <li>0:30\u20131:00 \u2013 Controllo del serbatoio: verificare swpd e si\/so. si\/so costantemente &gt; 0? \u2192 pressione effettiva del serbatoio. free irrilevante.<\/li>\n  <li>1:00\u20131:30 \u2013 Contesto I\/O: bi\/bo vs. wa. Valori elevati di bi\/bo senza wa? \u2192 L\u2019I\/O viene disattivato. Valori elevati di wa con bi\/bo moderati? \u2192 Latenza\/Lock\/I\/O remoto.<\/li>\n  <li>1:30\u20132:00 \u2013 Sezione \u201csystem\u201d: in\/cs rispetto a sy. cs molto alto? \u2192 Verificare la pressione di cambio di contesto, il parallelismo\/il locking.<\/li>\n  <li>2:00\u20133:00 \u2013 Definire l'ipotesi e scegliere lo strumento appropriato: iostat per l'indice I\/O, mpstat per le asimmetrie del kernel, pidstat per i punti critici dei processi. Solo dopo si passa alla messa a punto e al ridimensionamento.<\/li>\n<\/ul>\n\n<h2>Esempi avanzati tratti dalla pratica<\/h2>\n\n<ul>\n  <li><strong>Saturazione della CPU senza valori elevati di r<\/strong>: us+sy a 90%+, id \u2248 0, ma r moderato \u2192 hotspot single-thread o problema di affinit\u00e0. Soluzione: parallelizzare il percorso critico, verificare il core-pinning.<\/li>\n  <li><strong>Swap-Thrash<\/strong>: in entrambi i casi, chiaramente &gt; 0, b\/wa in aumento, us in calo \u2192 RAM decisamente insufficiente o heap dimensionato in modo errato. Misure: aumentare la RAM, ridurre il working set, regolare lo swappiness.<\/li>\n  <li><strong>Overhead del kernel<\/strong>: sy alto, cs\/in alto, us moderato \u2192 molte piccole chiamate di sistema\/I\/O. Soluzione: elaborazione in batch, riduzione delle chiamate di sistema, verificare le opzioni di montaggio del filesystem.<\/li>\n  <li><strong>Congestione dei writeback<\/strong>: wa alto, bo alto, onde corte \u2192 limiti \"dirty\" troppo elevati, latenza di archiviazione variabile. Verificare la messa a punto del writeback e lo scheduler I\/O.<\/li>\n  <li><strong>Pressione della virtualizzazione<\/strong>: st visibile, r oscilla, id \u201esalta\u201c \u2192 l\u2019host condivide la CPU. Soluzione: verificare l\u2019assegnazione\/il posizionamento delle vCPU, ridurre l\u2019overcommit.<\/li>\n<\/ul>\n\n<h2>Conoscere i limiti di vmstat<\/h2>\n\n<p>Vmstat \u00e8 un eccellente <strong>Sensore di allarme preventivo<\/strong>, ma non \u00e8 un microscopio. Mi mostra dove si verifica il blocco, ma non il singolo file responsabile, la query o il thread. Per questo motivo, dopo la diagnosi con vmstat, ricorro sistematicamente a strumenti pi\u00f9 approfonditi, verifico le ipotesi da diverse angolazioni e poi modifico solo una cosa alla volta. In questo modo i miglioramenti rimangono misurabili e riproducibili.<\/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\/09\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riepilogo dalla pratica<\/h2>\n\n<p>Con vmstat riesco a capire in pochi secondi se sono la CPU, la RAM, lo swap o l'I\/O a rallentare il sistema, analizzando l'interazione tra r, b, si\/so, bi\/bo e us\/sy\/id\/wa\/st <strong>leggi<\/strong>. Valuto le tendenze anzich\u00e9 i singoli valori, effettuo confronti con i valori di riferimento e, se necessario, prendo in considerazione iostat, mpstat, pidstat e le misurazioni storiche. Ignoro la prima riga in caso di anomalie acute e mi concentro sulle righe successive con frequenza di campionamento fissa. Prendo decisioni basate sui dati: r rispetto ai core, si\/so costantemente diversi da 0, wa persistentemente elevato, us+sy vicini al pieno carico. In questo modo deduco rapidamente misure concrete e mantengo i sistemi in condizioni ottimali <strong>reattivo<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Impara a interpretare correttamente vmstat su Linux per individuare i colli di bottiglia relativi a CPU, memoria e I\/O e ottimizzare la tua analisi delle prestazioni utilizzando la parola chiave \"vmstat linux\".<\/p>","protected":false},"author":1,"featured_media":21476,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-21483","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":"84","_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":"vmstat linux","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":"21476","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21483","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=21483"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21483\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21476"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}