Padroneggiare le Prestazioni: Una Guida Pratica all'Utilizzo del Toolset Sysstat

Il lavoro sulle prestazioni diventa complicato quando hai solo il momento presente. Un server è lento ora, ma lo era dieci minuti fa? Il disco ha iniziato a fare backup prima che la CPU salisse? Il problema è iniziato dopo il cron job, il deploy o la finestra di backup? Il toolset sysstat è utile perché ti fornisce sia letture in tempo reale che una registrazione storica con cui confrontare.

Lo strumento principale è sar, il System Activity Reporter. Lo uso quando top è troppo breve, quando un incidente è già passato, o quando devo dimostrare che un problema era di storage, pressione della memoria, traffico di rete o saturazione della CPU invece di indovinare dai sintomi. Il resto della suite, specialmente iostat e mpstat, fornisce dettagli quando sar ti indica un probabile collo di bottiglia.

Questo non sostituisce un'osservabilità completa. Hai ancora bisogno di metriche dell'applicazione, log, tracing e controlli esterni. Ma su un host Linux, sysstat è uno dei modi più veloci per rispondere alla prima domanda pratica: cosa stava effettivamente facendo la macchina?

1. Installazione e Configurazione Iniziale di Sysstat

Il pacchetto sysstat è tipicamente disponibile nei repository standard di tutte le principali distribuzioni Linux.

1.1 Comandi di Installazione

Usa il comando del gestore pacchetti appropriato per il tuo sistema:

Debian/Ubuntu:

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora:

sudo yum install sysstat
# oppure usa dnf per i sistemi più recenti
sudo dnf install sysstat

1.2 Abilitazione della Raccolta Dati Storici

Affinché sar sia veramente utile, deve raccogliere dati storicamente. Di default, l'installazione spesso configura un cron job o un timer systemd, ma la verifica è cruciale.

Sui sistemi moderni, assicurati che il servizio sysstat sia attivo:

sudo systemctl enable --now sysstat

File di Configurazione

La frequenza della raccolta dati è controllata dai file di configurazione, tipicamente situati in /etc/default/sysstat (Debian/Ubuntu) o /etc/sysconfig/sysstat (RHEL/CentOS). Cerca l'impostazione ENABLED o HISTORY. Impostare ENABLED="true" garantisce la raccolta giornaliera dei dati.

Suggerimento: Di default, i file di dati di sysstat sono memorizzati in /var/log/sa/ con nomi file come saXX dove XX è il giorno del mese. Alcuni sistemi basati su Debian espongono anche i report in /var/log/sysstat/. Controlla i valori predefiniti del tuo pacchetto prima di assumere il percorso.

Dopo aver abilitato la raccolta, attendi almeno un intervallo e conferma che i file stiano apparendo:

ls -lh /var/log/sa/

Se la directory è vuota, controlla i timer systemd:

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

Sui sistemi più vecchi, la raccolta potrebbe essere ancora guidata da cron. Il confezionamento esatto varia a seconda della distribuzione, quindi verifica invece di fare affidamento sulla memoria di un altro server.

2. L'Utility Principale: System Activity Reporter (`sar`)

sar è l'interfaccia principale per visualizzare le statistiche. Può mostrare dati in tempo reale o analizzare dati storici precedentemente raccolti.

2.1 Sintassi di Base per il Monitoraggio in Tempo Reale

La sintassi di base è progettata per riportare metriche specifiche a un intervallo specificato per un numero definito di volte.

sar [opzioni] [intervallo] [conteggio]

Esempio: Per riportare le statistiche generali della CPU ogni 3 secondi, 10 volte:

sar -u 3 10

Questo comando è utile durante un incidente perché ti fornisce un breve campione mobile invece di un singolo snapshot. Una singola riga può catturare un secondo tranquillo e trarre in inganno. Dieci campioni in trenta secondi mostrano se il pattern è costante, a picchi o già passato.

Opzione	Descrizione
`-u`	Utilizzo della CPU (default)
`-r`	Statistiche di memoria e paging
`-d`	Attività dei dispositivi a blocchi (I/O del disco)
`-n`	Statistiche di rete (es. `-n DEV` per le statistiche dell'interfaccia)
`-q`	Coda di esecuzione e carico medio
`-W`	Attività di swapping (paging)
`-A`	Tutte le metriche (utile per snapshot completi)

Per i file storici, la forma è la stessa. Aggiungi -f per scegliere il file di dati e spesso -s e -e per limitare l'intervallo di tempo. Questo è importante perché leggere un'intera giornata di output durante un'interruzione è lento e rumoroso.

3. Metriche Chiave delle Prestazioni ed Esempi Pratici di `sar`

Comprendere l'output di sar richiede la conoscenza di quali metriche indicano salute o stress delle prestazioni.

3.1 Utilizzo della CPU (`sar -u`)

L'utilizzo della CPU è spesso il primo posto dove cercare i colli di bottiglia. Un utilizzo elevato in categorie specifiche indica la natura del carico di lavoro.

sar -u 5 3

Metrica	Descrizione	Indicatore di Collo di Bottiglia
`%user`	Tempo CPU speso per eseguire processi a livello utente.	Alto indica saturazione dell'applicazione/servizio.
`%system`	Tempo CPU speso per eseguire attività del kernel/sistema.	Alto suggerisce chiamate di sistema intensive o problemi di driver.
`%iowait`	Tempo CPU inattivo in attesa di operazioni I/O (disco/rete).	Alto indica un collo di bottiglia I/O, non una carenza di CPU.
`%idle`	Tempo CPU speso in attesa di nulla (disponibile).	Basso (es. < 5%) suggerisce saturazione della CPU.

Fai attenzione con %iowait. Viene spesso frainteso come "la CPU è occupata con il disco". In realtà significa che la CPU era inattiva mentre almeno una richiesta I/O era in sospeso. Un valore alto può puntare verso la latenza dello storage, ma necessita di conferma con le metriche del disco. Su un server di database, ad esempio, un %iowait alto combinato con un await del disco alto è un segnale molto più forte di %iowait da solo.

Un'altra utile vista della CPU è la coda di esecuzione:

sar -q 5 5

runq-sz mostra quanti task sono in attesa di essere eseguiti. Se il carico medio è alto ma runq-sz è modesto e %iowait è alto, potresti avere a che fare con I/O bloccato piuttosto che con pura pressione della CPU. Se runq-sz rimane alto e %idle è vicino allo zero, la macchina probabilmente ha bisogno di meno processi eseguibili, codice più veloce o più capacità della CPU.

3.2 Memoria e Paging (`sar -r` e `sar -W`)

Le statistiche della memoria rivelano sia il consumo che se il sistema sta ricorrendo allo swapping o al paging.

Utilizzo della Memoria (sar -r):

sar -r 1 5

Concentrati su kbavail (memoria disponibile). Se kbmemfree è basso, ma kbcached e kbbuffers sono alti, la memoria viene utilizzata in modo efficiente dal meccanismo di caching del kernel.

Attività di Swapping (sar -W):

sar -W 1 5

Guarda pswpin/s (pagine swapped in) e pswpout/s (pagine swapped out). Qualsiasi valore significativo diverso da zero qui indica che il sistema sta facendo swapping in modo aggressivo, segnalando pressione della memoria (un forte collo di bottiglia).

L'output della memoria di Linux può sembrare allarmante finché non ricordi che la cache non è memoria sprecata. Un server con pochissima kbmemfree potrebbe essere ancora sano se kbavail è confortevole e l'attività di swap è silenziosa. Il pattern pericoloso è diverso: la memoria disponibile diminuisce, appare l'attività di swap-in e swap-out e la latenza dell'applicazione aumenta. Questo ti dice che i processi stanno toccando memoria che non entra più nella RAM.

Per un server web, questo potrebbe accadere dopo un deploy che raddoppia accidentalmente il numero di worker. Per un host batch, potrebbe accadere quando due grandi lavori si sovrappongono. sar non ti dirà quale processo lo ha causato, ma ti fornisce la timeline. Abbinalo a ps, top, log di servizio o metriche cgroup per identificare il proprietario.

3.3 Attività I/O del Disco (`sar -d`)

Il monitoraggio dell'attività del disco è cruciale per i server di database o i sistemi di storage pesantemente utilizzati.

sar -d 3 5

Questo output richiede l'identificazione dei dispositivi specifici (es. sda, vda). Le metriche chiave includono:

tps: Trasferimenti al secondo (un valore alto indica richieste I/O elevate).
rd_sec/s e wr_sec/s: Quantità di dati letti/scritti al secondo.
%util: Percentuale di tempo in cui il dispositivo era occupato a servire le richieste. Se %util rimane vicino al 100% su un dispositivo a blocchi tradizionale, lo storage potrebbe essere saturo.

Sugli SSD moderni e i dischi virtuali, %util merita contesto. Alcuni dispositivi gestiscono bene l'I/O parallelo, e i volumi cloud possono essere limitati da IOPS provisionati, throughput o crediti burst. Tratta %util come un invito a guardare più da vicino, non come una diagnosi completa. Conferma con iostat -xd, la latenza dell'applicazione e le metriche di storage a livello di piattaforma se sei su AWS, Azure, GCP o un altro ambiente virtualizzato.

Un flusso di lavoro pratico è:

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

Usa sar per trovare l'ora brutta, poi usa iostat durante una ricorrenza dal vivo per ispezionare la latenza a livello di dispositivo.

3.4 Statistiche di Rete (`sar -n`)

sar può riportare l'attività attraverso vari livelli di rete. Il controllo più comune è l'attività dell'interfaccia (DEV).

sar -n DEV 5 1

Questo comando mostra metriche come rxpk/s (pacchetti ricevuti al secondo) e txkB/s (kilobyte trasmessi al secondo) per ogni interfaccia di rete. Usalo per identificare le interfacce che subiscono un carico pesante o potenziali errori.

Per i contatori di errore, aggiungi EDEV:

sar -n EDEV 5 3

Questo può mostrare errori di ricezione, errori di trasmissione, drop e collisioni dove supportati dal driver. I drop sono particolarmente utili quando un servizio si lamenta di timeout intermittenti ma CPU e disco sembrano normali. Se i drop aumentano durante i picchi di traffico, potresti dover ispezionare le code NIC, le impostazioni di rete del kernel, il networking dei container o il percorso del load balancer.

Per il comportamento a livello TCP, prova:

sar -n TCP,ETCP 5 3

Ritrasmissioni, reset e tentativi di connessione falliti possono trasformare un vago report "il sito è lento" in un problema di rete o upstream più specifico.

4. Analisi Storica e Creazione di Baseline

Il vero potere di sysstat risiede nella sua capacità di analizzare l'attività del sistema per periodi prolungati, essenziale per stabilire baseline delle prestazioni (cosa è normale per il tuo sistema).

4.1 Analisi dei Giorni Precedenti

Per visualizzare i dati raccolti in un giorno precedente, usa il flag -f per specificare il percorso del file saXX giornaliero.

Esempio: Per visualizzare le statistiche della CPU dal 10° giorno del mese corrente:

sar -u -f /var/log/sa/sa10

Per rivedere le statistiche in una specifica finestra temporale di quel giorno, aggiungi i flag -s (ora di inizio) e -e (ora di fine) (usando il formato 24 ore).

# Visualizza le statistiche di rete dalle 14:00 alle 16:30 del giorno 10
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 Stabilire le Baseline

Raccogli Dati: Esegui sysstat attraverso periodi normali di alto e basso carico.
Identifica le Norme: Analizza i dati storici (sar -f) per determinare l'utilizzo medio della CPU (%user, %system), la latenza di picco dell'I/O (%util) e l'utilizzo medio della memoria.
Definisci le Soglie: Tratta le deviazioni sostenute dalla tua baseline come trigger di indagine. Un host di database occupato e un jump box tranquillo non dovrebbero condividere le stesse soglie.

Le baseline sono più utili quando sono legate a ritmi aziendali reali. Un'importazione batch del lunedì mattina, un backup notturno e un lancio di prodotto creano tutte diverse forme "normali". Prendi appunti quando indaghi: "backup iniziato alle 01:00", "nuova release alle 14:30", "email di marketing alle 09:05". Quelle note rendono l'output storico di sar molto più facile da interpretare in seguito.

5. Strumenti di Supporto di Sysstat

Mentre sar è lo strumento ombrello, la suite sysstat include utility specializzate che offrono report mirati e ad alto dettaglio.

5.1 iostat (Statistiche di Input/Output)

iostat fornisce metriche dettagliate specificamente focalizzate sull'utilizzo del dispositivo, particolarmente utile quando si diagnosticano colli di bottiglia dello storage.

# Riporta le statistiche del disco ogni 2 secondi, 4 volte, incluse le statistiche estese (x)
iostat -xd 2 4

Metriche chiave di iostat:

%util: La percentuale di tempo CPU durante la quale sono state emesse richieste I/O al dispositivo (indicatore cruciale di saturazione).
await: Il tempo medio di attesa (in millisecondi) per le richieste I/O emesse al dispositivo. Un await alto indica una lenta reattività dello storage.

Se await aumenta ma il throughput non è alto, cerca I/O casuali piccoli, problemi del filesystem, vicini rumorosi sull'infrastruttura virtuale o un'applicazione che fa scritture sync-heavy. Se il throughput è alto e la latenza aumenta con esso, il dispositivo potrebbe essere semplicemente al suo limite pratico.

5.2 mpstat (Statistiche Multi-Processore)

Se sospetti problemi di scheduling della CPU o una distribuzione non uniforme del carico di lavoro tra i core, mpstat fornisce statistiche di utilizzo per processore, qualcosa che sar -u aggrega.

# Mostra l'utilizzo per tutte le CPU (A) ogni 2 secondi
mpstat -P ALL 2 1

Questo è prezioso per identificare applicazioni single-threaded che saturano un singolo core mentre altri rimangono inattivi, o per diagnosticare l'efficienza dell'hyperthreading.

5.3 sadf (Esportazione dei Dati di Sysstat)

sadf legge gli stessi dati raccolti di sar ma può stamparli in formati che sono più facili da consumare per script e dashboard.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

L'output -d è utile per l'elaborazione di testo delimitato. L'output -j è utile quando vuoi JSON. Questo è comodo quando devi allegare prove a una revisione di incidente o confrontare due host senza copiare manualmente l'output del terminale.

6. Un Percorso Pratico per un Incidente

Immagina un server API che ha iniziato a dare timeout alle 10:15. I log dell'applicazione mostrano richieste in accumulo, ma non spiegano perché. Inizia con la vista storica della CPU:

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Se %user è alto e %idle è basso, l'app potrebbe essere CPU-bound. Controlla l'utilizzo per core:

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Se un core è bloccato mentre altri sono tranquilli, sospetta un worker single-threaded, un hot lock o una distribuzione non uniforme dei processi. Se tutti i core sono occupati, guarda il tasso di richieste, i deploy recenti e i percorsi di codice costosi.

Se la CPU sembra per lo più inattiva ma %iowait aumenta, passa al disco:

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Un'elevata utilizzazione del dispositivo o una profondità della coda in aumento intorno allo stesso momento puntano verso lo storage. Su un servizio basato su database, la prossima tappa sono i log del database e i dati delle query lente. Su un host che serve file, controlla se un backup, un lavoro di compressione o una rotazione dei log sono stati eseguiti nello stesso momento.

Se CPU e disco sembrano a posto, ispeziona memoria e rete:

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Il punto non è eseguire ogni comando ogni volta. Il punto è seguire le prove. sar ti fornisce una timeline attraverso le classi di risorse, che di solito è ciò di cui hai bisogno per smettere di inseguire il sintomo più rumoroso.

Una Semplice Abitudine Operativa

Il modo migliore per imparare sysstat è usarlo prima che qualcosa si rompa. Controlla un server sano durante il traffico normale. Controllalo durante i backup. Controllalo dopo un deploy. Salva alcuni pattern di comando che corrispondono al tuo ambiente.

Quando si verifica un incidente, saprai già come appare la normalità. Questo è il vero valore del toolset. sar, iostat, mpstat e sadf non diagnosticano magicamente l'applicazione per te, ma mantengono la conversazione ancorata alle prove: quando è iniziato il problema, quale risorsa è cambiata e se l'host era effettivamente sotto pressione.