Osserva l'utilizzo delle risorse e la saturazione, poi conferma con misurazione. Un approccio sistematico — il metodo USE (Utilization, Saturation, Errors) — controlla ogni risorsa in modo che tu non incolpi quella sbagliata.
Per ogni risorsa (CPU, memoria, disco, rete), poni tre domande:
UTILIZATION → how busy is it (% time in use)?
SATURATION → how much queued/waiting work (load, run queue, swap)?
ERRORS → any errors (dropped packets, disk errors, OOM kills)?
→ a resource that is saturated, not just busy, is usually the bottleneck.
Ogni risorsa ha una firma distintiva che puoi leggere con strumenti standard:
CPU → top/htop: high %us or load > #cores, run queue backed up
MEMORY → free/vmstat: low free RAM + high SWAP in/out (si/so) → swapping = thrashing
DISK I/O→ iostat/vmstat: high %iowait, %util ~100%, high await → I/O-bound
NETWORK → iftop/sar/ss: bandwidth saturated, retransmits, high latency
Le distinzioni chiave: alto carico con alto %us significa CPU-bound; swapping (si/so) significa pressione sulla memoria; alto %iowait significa che la CPU è inattiva in attesa del disco; alta latenza/ritrasmissioni punta alla rete.
$ vmstat 1
r b swpd free si so bi bo us sy id wa
8 0 0 120m 0 0 12 20 92 6 2 0 ← CPU-bound (id=0, wa=0)
1 3 800m 30m 40 120 900 8 5 3 2 90 ← I/O + swap (wa=90, so>0)
Non fermarti a un solo numero. Profila il processo (ad es. perf, un profiler CPU/heap) per trovare la funzione calda o l'allocazione, cambia una cosa, e rimisura. I sintomi possono ingannare — alta CPU potrebbe essere davvero un busy-wait causato da contesa di lock, non da lavoro reale.
Fissare la risorsa sbagliata (aggiungere RAM a una macchina CPU-bound) spreca denaro e non aiuta. Il metodo USE più lo strumento giusto isola il vincolo reale velocemente, e rimisurare conferma che la correzione ha spostato l'ago della bilancia.