Privește utilizarea resurselor și saturația, apoi confirmă prin măsurare. O abordare sistematică — metoda USE (Utilization, Saturation, Errors) — verifică fiecare resursă, pentru ca să nu blamezi pe cea greșită.
Pentru fiecare resursă (CPU, memorie, disc, rețea), pune trei întrebări:
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.
Fiecare resursă are o semnătură distinctă pe care o poți citi cu unelte 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
Distincțiile cheie: sarcină mare cu %us mare înseamnă CPU-bound; swapping (si/so) înseamnă presiune de memorie; %iowait mare înseamnă că CPU este inactiv așteptând disc; latență/retransmisii mari indică rețeaua.
$ 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)
Nu te opri niciodată la un singur număr. Profilează procesul (de ex. perf, un profiler CPU/heap) pentru a găsi funcția fierbinte sau alocarea, schimbă un lucru și măsoară din nou. Simptomele pot fi înșelătoare — CPU mare ar putea fi de fapt o așteptare ocupată cauzată de contenție de blocare, nu muncă reală.
Repara resursa greșită (adaugă RAM într-o cutie CPU-bound) risipă bani și nu ajută. Metoda USE plus uneltele potrivite izolează repede constrângerea reală, iar măsurarea din nou confirmă că reparația a mișcat acul.