Kijk naar resourcegebruik en verzadiging, en bevestig dit vervolgens met meting. Een systematische benadering — de USE-methode (Utilization, Saturation, Errors) — controleert elke resource zodat je niet de verkeerde beschuldigt.
Voor elke resource (CPU, geheugen, schijf, netwerk) stel je drie vragen:
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.
Elke resource heeft een unieke handtekening die je met standaardtools kunt aflezen:
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
De belangrijkste onderscheidingen: hoge belasting met hoge %us betekent CPU-gebonden; swapping (si/so) betekent geheugendruk; hoge %iowait betekent dat de CPU inactief is wachtend op schijf; hoge latentie/hertransmissies wijzen op het netwerk.
$ 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)
Stop niet bij één getal. Profiel het proces (bijv. perf, een CPU/heap profiler) om de warme functie of toewijzing te vinden, wijzig één ding en meet opnieuw. Symptomen kunnen misleidend zijn — hoge CPU kan eigenlijk een drukke wacht zijn veroorzaakt door vergrendeling, niet echt werk.
Het repareren van de verkeerde resource (RAM toevoegen aan een CPU-gebonden doos) verspilt geld en helpt niet. De USE-methode plus het juiste gereedschap isoleert snel de echte beperking, en het opnieuw meten bevestigt dat de fix de naald heeft verplaatst.