Se il nostro sistema linux diventa spesso lento e "non responsivo" in genere questa cosa si riflette nel fattore di carico del sistema (system load). Una analisi di questo fattore ci può permettere di individuare il collo di bottiglia della nostra macchina (in genere riconducibile a 2 fattori: cpu o disco).

Per vedere il carico di sistema occorre eseguire il comando "uptime" (o il comando "w"):

11:54:57 up 1 day,  2:00,  2 users,  load average: 0,77, 0,84, 1,05

Gli ultimi 3 numeri rappresentano il carico medio nell'ultimo minuto, negli ultimi 5 minuti e negli ultimi 15.

Per capire questo numero occorre conoscere il numero di core della nostra cpu ("cat /proc/cpuinfo | grep processor | wc -l" o "nproc"). Se il carico rimane sotto questo valore, allora è tutto a posto: la cpu riesce a "stare dietro" ai processi, e non c'è alcun rallentamento. Se il carico diventa superiore a questo dato significa che alcuni processi sono rallentati, in quanto sono spesso in attesa che la cpu sia libera per soddisfarli. Se il carico diventa molto superiore, e se si riflette in particolare nel 2° e 3° dato, quindi è una cosa che si protrae nel tempo, è male!

Per analizzare meglio lo stato del sistema e della cpu usiamo il comando vmstat.

VMSTAT

Eseguiamo il comando "vmstat 1", che mostra una linea di statistiche al secondo (nella prima linea è presente la media dal boot).

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0      0 179428  48236 510464   12   14   118   219  425   79 23  1 70  5
 0  0      0 179260  48248 510468    0    0     0   220  819 2412 17  1 79  4
 2  0      0 176204  48280 510456    0    0     8   124  933 2330 23  1 62 13

Questo il significato delle colonne:

r: Numero di processi in attesa di CPU. Se è spesso superiore a 2*(numero core) molto probabilmente il problema è nella CPU

b: Numero di processi bloccati (dormienti). Non stanno facendo nulla, normalmente in attesa di I/O (spesso disco), ma non è detto al 100%.

swpd: Quantità di swap usata

free: Quantità di memoria fisica libera

buff: Quantità di memoria usata per i buffer (usata per velocizzare alcune operazioni su disco)

cache: Memoria usata come cache

si: Fattore di ritorno dello swap (da disco a RAM)

so: Fattore di uscita dello swap (da RAM a disco)

bi: Scritture I/O in blocchi/secondo

bo: Letture I/O in blocchi/secondo

in: Numero di interrupt al secondo

cs: Numero di context switch al secondo

us: Percentuale di CPU impegnata in processi utente (le applicazioni)

sy: Percentuale di CPU impegnata in processi di sistema (kernel)

id: Percentuale di CPU libera

wa: Percentuale di CPU passata in attesa di I/O

Come leggere velocemente questi dati

Guardiamo come prima cosa la colonna "wa": se questo valore è spesso alto il problema è da ricercarsi nell'I/O (poca ram o hard disk troppo lento o con troppe operazioni), tanto che la nostra CPU è spesso bloccata in sua attesa.

In questo caso guardiamo anche le colonne relative allo swap, "si" e "so": se sono spesso sopra lo 0 significa che il sistema usa molto lo swap, e questo avviene quando finisce la memoria RAM.

In caso contrario guardiamo alla colonna "id", che ci dice quanto la CPU è "rilassata". Se è troppo spesso uguale a 0 significa che non lo è per niente, la CPU è spesso impegnata al 100% a seguire i processi di sistema (sy) o utente (us). Se il problema è nei processi di sistema si può cercare il problema in demoni di sistema o in altri processi in background di root (una causa comune è il firewall di sistema e il suo "iptable"). Se il problema è nei processi utenti conviene usare un programma come "top" per vedere qual'è il processo che sta mangiando la CPU.

IOSTAT

Se abbiamo problemi di I/O possiamo analizzarli ancora meglio con il comando "iostat -x 5" (statistiche ogni 5 secondi). Questo comando in particolare ci permette di determinare quale hard disk è impegnato, e su cosa.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          21,92    1,02    1,33    5,02    0,00   70,72
 
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0,21     0,00    0,01    0,00     0,14     0,00    25,88     0,00    4,34    4,34    0,00   2,45   0,00
sda               1,37     8,49    5,80    4,73   105,14   202,04    58,35     0,55   52,15   15,96   96,52   5,38   5,66

Guardiamo per prima cosa la colonna "%util". Se è prossima al 100% significa che quel disco è troppo impegnato.

La colonna "await" indica quanto tempo il disco perde per servire una richiesta. Se molto alto siamo di fronte probabilmente a saturazione del disco.

Senza entrare troppo in dettagli, gli altri dati possono permetterci di capire se il problema del disco è maggiormente incentrato in letture o in scritture.

ALTRO

top

Per vedere i processi utenti che usano molto tempo di CPU.

iotop

Simile a top, ma incentrato sull'utilizzo dell I/O, in tempo reale. Da notare che se il problema di I/O è relativo a processi kernel sarà difficilmente tracciabile in maniera precisa con questo comando.

ps awwlx --sort=vsz | tail -n 10

Il comando permette di analizzare i processi con la dimensione virtuale maggiore (la dimensione virtuale contiene le librerie condivise, e anche i blocchi spostati su disco per "swap out"). Questo in particolare può individuare i processi che fanno maggiormente uso di swap.

munin

Un ottimo tool che permette di mantenere uno storico di vari dati del sistema, graficandoli e permettendoci quindi una analisi nel tempo.

munin-monitoring.org

Novita 2014: dstat

Piccolo aggiornamento per segnalare questo tool scoperto oggi: DSTAT

Sembra essere molto interessante in quanto unisce i monitoring fatti dai tool vmstat, iostat, netstat and ifstat

http://lintut.com/dstat-linux-monitoring-tools/

CREDITS

Buona parte di questo articolo è una traduzione e rimaneggiamento di questo:

http://www.tummy.com/Community/Articles/isolating-heavy-load/

Ho aggiunto qualche informazione di dettaglio su vmstat e poco altro, ma magari lo evolvo nel tempo...