Schau dir Ressourcenauslastung und Sättigung an, bestätige dann mit Messungen. Ein systematischer Ansatz — die USE-Methode (Utilization, Saturation, Errors) — prüft jede Ressource, damit du nicht die falsche beschuldigst.
Für jede Ressource (CPU, Speicher, Festplatte, Netzwerk) stellst du drei Fragen:
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.
Jede Ressource hat eine charakteristische Signatur, die du mit Standard-Tools erkennen kannst:
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
Die wichtigsten Unterscheidungen: hohe Last mit hohem %us bedeutet CPU-gebunden; Swapping (si/so) bedeutet Speicherdruck; hoher %iowait bedeutet, die CPU ist untätig und wartet auf die Festplatte; hohe Latenz/Neuübertragungen deuten auf das Netzwerk hin.
$ 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)
Hör bei einer Zahl nicht auf. Profiliere den Prozess (z. B. perf, ein CPU-/Heap-Profiler), um die Hot-Funktion oder Speicherallokation zu finden, ändere eine Sache und messe erneut. Symptome können trügerisch sein — hohe CPU könnte eigentlich ein Busy-Wait sein, das durch Lock-Contention verursacht wird, nicht echte Arbeit.
Die falsche Ressource zu optimieren (RAM zu einer CPU-gebundenen Box hinzufügen) verschwendet Geld und hilft nicht. Die USE-Methode plus das richtige Tool isoliert schnell die echte Beschränkung, und erneute Messungen bestätigen, dass die Optimierung einen Unterschied gemacht hat.