Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz

Die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz ist in vielen Produktionsumgebungen der schnellste Weg, um „mysteriöse“ Performance-Probleme sauber einzugrenzen. In der Praxis treten diese drei Signale häufig gemeinsam auf, weil sie sich gegenseitig verstärken: Wenn CPU-Ressourcen knapp werden, kann der Kernel Netzwerkarbeit nicht mehr rechtzeitig erledigen; Warteschlangen füllen sich; Pakete werden verworfen; TCP reagiert mit Retransmissions und Backoff; und die End-to-End-Latenz steigt sprunghaft. Besonders tückisch ist, dass die Symptome nicht immer dort sichtbar sind, wo die Ursache liegt. Eine API zeigt hohe p99-Latenz, aber die eigentliche Ursache ist CPU-Saturation auf Nodes, die wiederum zu Drops in RX/TX-Rings oder qdisc-Queues führt. Wer diese Kette versteht und in Metriken korrekt abbildet, kann Incidents schneller triagieren, falsche Hypothesen vermeiden und gezielt mitigieren – etwa durch korrektes CPU- und IRQ-Tuning, bessere Queue-Disziplinen, Anpassungen bei CNI/Service-Mesh oder schlicht durch Kapazität. Dieser Artikel erklärt, wie die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz technisch entsteht, welche Metriken Sie wirklich brauchen, wie Sie Kausalität von Zufall unterscheiden und welche typischen Muster in Kubernetes-, Cloud- und Bare-Metal-Umgebungen auftreten.

Warum CPU-Saturation, Packet Drops und Latenz oft zusammen auftreten

Netzwerkperformance ist keine reine „Leitungsthematik“. Selbst wenn Bandbreite und RTT auf dem Papier gut sind, entsteht Latenz durch Verarbeitung und Warteschlangen im Host: Interrupt-Verarbeitung, SoftIRQ, Packet Classification, Conntrack, iptables/nftables, eBPF-Programme, Sidecars/Proxies und die Applikation selbst. Sobald die CPU ausgelastet ist – besonders einzelne Cores –, verschiebt sich Arbeit in Warteschlangen. Werden diese Warteschlangen zu groß, entstehen Drops. Und Drops bedeuten nicht nur „fehlende Pakete“, sondern führen bei TCP zu Retransmissions und bei vielen Protokollen zu Wiederholungen auf höherer Ebene. Das erhöht Last und verschlechtert die CPU-Situation zusätzlich.

Ein wichtiger Punkt: „CPU-Saturation“ heißt nicht zwingend 100% CPU im Gesamtsystem. Häufig reicht ein saturierter Core (z. B. durch IRQ-Affinität, SoftIRQ-Last, ein Sidecar oder einen Single-Threaded Hotspot), um Netzwerkpfade zu verlangsamen. In Kubernetes tritt das oft auf Nodes auf, wenn mehrere Pods denselben CPU-Pool teilen und Netzwerk-Interrupts unglücklich auf wenige Cores gebunden sind.

Die Ursache-Wirkung-Kette im Detail

Damit die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz nicht nur „gefühlt“ ist, hilft eine klare Kette:

• CPU-Saturation: CPU-Zeit ist knapp, SoftIRQ und Kernel-Netzwerkpfad konkurrieren mit Applikation/Sidecar.
• Queueing: RX/TX-Rings, qdisc-Queues, Socket-Buffers und Userspace-Queues füllen sich.
• Packet Drops: Wenn Puffer voll sind oder Verarbeitung nicht nachkommt, werden Pakete verworfen (Kernel, NIC, qdisc).
• Retransmissions/Backoff: TCP erkennt Verlust, sendet erneut und reduziert sein Congestion Window; Latenz steigt.
• End-to-End-Latenz: p95/p99 steigen; Timeouts nehmen zu; Retry-Mechanismen verstärken Traffic und CPU-Last.

Die entscheidende Diagnosefrage lautet: Entsteht Latenz primär durch Wartezeit (Queues) oder durch Wiederholungen (Drops/Retransmits) – oder durch beides? Diese Unterscheidung bestimmt die Mitigation.

Welche Arten von Packet Drops es gibt und warum das wichtig ist

„Packet Drops“ ist ein Sammelbegriff. Für eine saubere Korrelation müssen Sie wissen, wo gedroppt wird:

• NIC/Ring-Drops: Drops auf der Netzwerkkarte oder im Treiber, wenn RX/TX-Rings voll sind oder Interrupts nicht schnell genug abgearbeitet werden.
• Kernel/qdisc-Drops: Drops in Queueing-Disziplinen (z. B. pfifo_fast, fq_codel), wenn die Warteschlange überläuft.
• Socket-Buffer-Drops: Drops, wenn Empfangs-/Sende-Puffer (rmem/wmem) nicht ausreichen oder der Userspace nicht nachkommt.
• Conntrack-/Firewall-bezogene Drops: Indirekte Drops durch Überlast (Conntrack full), hoher CPU-Aufwand in iptables/nftables oder eBPF.
• Overlay-/Tunnel-Drops: Fragmentierung/MTU-Probleme, Encapsulation-Overhead, zusätzliche Verarbeitung in CNI/Overlay.

Wenn Sie Drops nur als „irgendwo dropped“ betrachten, riskieren Sie falsche Maßnahmen. NIC-Drops beheben Sie anders als qdisc-Drops oder Conntrack-Probleme. Hilfreich für Grundlagen der Linux-Netzwerk-Queueing-Disziplinen ist die Traffic-Control-Dokumentation, z. B. über das Linux-tc-Subsystem: tc(8) Manual.

CPU-Saturation korrekt messen: Nicht nur „CPU %“

Für die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz reicht „CPU-Auslastung“ als einzelne Metrik nicht. Sie brauchen mindestens folgende Sicht:

• CPU Utilization pro Core: Nicht nur Node-gesamt, sondern pro CPU, um Hotspots zu erkennen.
• CPU Steal (Cloud): In virtualisierten Umgebungen kann „steal“ bedeuten, dass Ihnen CPU-Zeit entzogen wird.
• Run Queue / Load Average: Gibt Hinweise, ob Prozesse warten, weil CPU fehlt.
• SoftIRQ/IRQ-Anteile: Hohe SoftIRQ-Zeit ist ein klassischer Indikator für Netzwerkpfad-Überlast.
• Context Switches / Scheduler Pressure: Hohe Wechsel können Latenz erhöhen, ohne dass CPU „100%“ zeigt.

Gerade für Netzwerkprobleme ist SoftIRQ zentral: Netzwerkpakete werden häufig im Kontext von SoftIRQs verarbeitet. Wenn SoftIRQ-Last steigt und CPU knapp ist, entstehen Verzögerungen und Drops. Eine gute Einstiegserklärung zu SoftIRQs und deren Diagnose liefern viele Linux-Performance-Guides, etwa die Kernel-Dokumentation zur Netzwerkverarbeitung und NAPI (konzeptionell): Linux Kernel Networking Docs.

Packet Drops messen: Welche Zähler wirklich zählen

Auch bei Drops gilt: Zähler sind nur dann wertvoll, wenn Sie sie richtig interpretieren und korrelieren. Typische Quellen:

• Interface-Zähler: RX/TX dropped, errors, overruns (z. B. via ip -s link).
• NIC-/Treiberstatistiken: Per ethtool -S oft detaillierter (Ring full, missed interrupts, etc.).
• qdisc-Statistiken: Per tc -s qdisc sehen Sie drops/overlimits/backlog pro Interface.
• Kernel-Netstat/SNMP: Zähler für TCP Retransmissions, RTOs, ListenDrops, PruneCalled etc.
• Conntrack-Zähler: Drops/Insert-Fails und „table full“-Indikatoren, je nach Setup.

Für TCP-Interpretation sind Retransmissions besonders wichtig, weil sie den Übergang „Drop → spürbare Latenz“ sichtbar machen. Ein Einstieg in TCP-Konzepte und Congestion Control findet sich z. B. in RFCs und technischen Übersichten; als verlässlicher Standard ist RFC 9293 (TCP) relevant: RFC 9293 (TCP).

Latenz messen: p50/p95/p99 und die Falle der Mittelwerte

In Produktionssystemen ist die Latenzverteilung entscheidend. CPU-Saturation und Drops schlagen meist zuerst in den Long Tail durch. Deshalb ist p99 häufig der erste Indikator, während p50 scheinbar stabil bleibt. Für die Korrelation ist es hilfreich, mehrere Latenzarten getrennt zu betrachten:

• Application Latency: Gemessen im Service (Request-Handling).
• Upstream/Downstream Latency: Client-seitig und server-seitig getrennt, um Netz vs. App zu trennen.
• Handshake-/Setup-Latenz: TCP Handshake, TLS Handshake – wichtig bei Connection Churn.
• Queueing-Latenz: Indirekt sichtbar über Backlog/Queue-Length und steigende p99.

Wenn Latenz steigt und gleichzeitig Drops/Retransmits steigen, ist die Wahrscheinlichkeit hoch, dass Netzwerkpfad und CPU zusammenhängen. Wenn Latenz steigt, aber Retransmits stabil bleiben, ist Queueing oder Applikationsverarbeitung wahrscheinlicher.

Queueing-Theorie als Werkzeug: Wann CPU-Saturation Latenz explodieren lässt

Eine einfache Intuition: Je näher ein System an 100% Auslastung kommt, desto stärker wächst die Warteschlange – und damit die Wartezeit. Das erklärt, warum Latenz oft nicht linear, sondern „plötzlich“ steigt. In vereinfachten Modellen (als Denkwerkzeug, nicht als exakte Prognose) nimmt die Wartezeit mit der Auslastung stark zu.

Als anschauliche Faustformel kann man die Abhängigkeit der Wartezeit von der Auslastung ρ (rho) betrachten. Je näher ρ an 1 liegt, desto größer wird die Warteschlange. Eine vereinfachte Darstellung ist:

$W\approx \frac{S}{1–\rho }$

Dabei ist W die Wartezeit, S eine typische Servicezeit (Verarbeitungszeit) und ρ die Auslastung. In der Praxis bedeutet das: Wenn CPU-Saturation ansteigt (höhere ρ), steigt die Wartezeit in verschiedenen Queues (SoftIRQ, qdisc, Userspace), und Latenz kann stark anwachsen – selbst bei unverändertem Traffic.

Das typische Korrelationsmuster im Incident

Ein sehr häufiges Muster in Produktionsincidents sieht so aus:

• Phase 1: p99-Latenz steigt langsam, CPU pro Core nähert sich Sättigung, SoftIRQ-Anteil steigt.
• Phase 2: Backlog/Queue-Length wächst, erste Packet Drops treten auf (qdisc oder NIC).
• Phase 3: TCP Retransmissions steigen, Errors nehmen zu (Timeouts, 503/504), Retry-Last erhöht Traffic.
• Phase 4: Positive Rückkopplung: Mehr Retries → mehr CPU → mehr Drops → noch mehr Latenz.

Dieses Muster erklärt, warum „ein bisschen CPU mehr“ im falschen Moment einen vollständigen Ausfall triggern kann. Gerade Retries sind dabei gefährlich, weil sie die Last in einer ohnehin saturierten Situation weiter erhöhen.

Wie Sie Korrelation von Kausalität unterscheiden

Dass CPU-Saturation, Drops und Latenz gleichzeitig auftreten, ist ein starkes Signal – aber nicht automatisch ein Beweis für die Richtung der Ursache. Für eine robuste Diagnose helfen Kontrollfragen:

• Was war zuerst? Steigt CPU vor den Drops? Oder steigen Drops zuerst (z. B. Netzwerkstörung) und CPU steigt durch Retries danach?
• Ist der Effekt lokal? Nur ein Node/Pod betroffen oder clusterweit? Lokale Effekte deuten auf CPU/IRQ/Noise hin.
• Gibt es ein Change-Event? Deployment, CNI-Änderung, Sidecar-Version, Kernel-Upgrade, neue iptables-Regeln?
• Ist Retransmissions-Anstieg sichtbar? Wenn ja, spricht das für tatsächlichen Paketverlust oder starke Jitter/Queueing.
• Verändert sich RTT außerhalb des Hosts? Wenn externe RTT stabil ist, liegt das Problem oft hostnah.

Als praktische Technik ist die zeitliche Korrelation (Lag) hilfreich: Wenn CPU-Spikes den Drops um Sekunden vorausgehen, ist CPU wahrscheinlicher Auslöser. Wenn Drops zuerst kommen, kann ein Netzwerk- oder Hardware-Problem ursächlich sein.

Häufige Ursachen für CPU-Saturation, die Packet Drops auslösen

• IRQ/SoftIRQ-Hotspot: Netzinterrupts landen auf wenigen Cores, die saturieren; RX-Verarbeitung hängt hinterher.
• Conntrack-Overhead: Hoher Flow-Churn, NAT/Masquerade oder viele kurze Verbindungen erhöhen CPU-Kosten.
• iptables/nftables-Regeln: Große Regelmengen oder komplexe Matches erhöhen per-Packet-CPU-Kosten.
• Service-Mesh/Sidecars: mTLS, L7-Parsing und Filterketten erhöhen CPU und können Cores saturieren.
• eBPF-Programme: Observability oder Policy kann pro Paket zusätzliche CPU kosten.
• Compression/Encryption: TLS ohne Offload, Kompression oder große Payloads erhöhen CPU-Zeit pro Request.
• CPU-Throttling (Cgroups): Pods werden gedrosselt, obwohl Node-CPU frei wirkt; Netzwerkverarbeitung leidet.

Typische Ursachen für Packet Drops, die CPU und Latenz nachziehen

Die Kausalrichtung kann auch umgekehrt sein: Drops entstehen primär durch Netzwerk oder Queueing, CPU steigt danach durch Retries, Logging und Error-Handling.

• Überlaufende qdisc-Queues: Egress ist blockiert, z. B. durch Policing oder Bandbreitenlimits; Queue überläuft.
• NIC-/Link-Probleme: Fehler, Flaps, Duplex-Mismatch (seltener in modernen Umgebungen), Driver Bugs.
• MTU/Fragmentierung: Path-MTU-Probleme führen zu Verlusten/Fragmentation; Retries erhöhen Last.
• Overlays/Tunnel: Zusätzliche Verarbeitung und Header-Overhead erhöhen Drop-Risiko bei knappen Buffern.

Mess-Set: Pflichtmetriken für die Korrelation

Wenn Sie ein Dashboard bauen, das die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz sauber abbildet, sollten mindestens diese Panels vorhanden sein:

• CPU pro Core + SoftIRQ-Anteil (Node und ggf. Pod/Container)
• Run Queue / Load / Throttling (CFS throttled time in Cgroups, wenn verfügbar)
• Interface RX/TX Drops + Errors pro Node und pro relevantes Interface
• qdisc Drops/Backlog (tc-Statistiken, wenn gesammelt)
• TCP Retransmissions (systemweit und idealerweise pro Node)
• Latenz p50/p95/p99 für kritische Endpoints (Client- und Server-Sicht)
• Error Rate (Timeouts, 5xx, gRPC codes) und Retry Rate (falls instrumentiert)

Wichtig ist die gemeinsame Zeitachse und identische Zeitfenster, damit die Korrelation nicht durch Dashboard-Artefakte verfälscht wird.

Diagnoseleitfaden: Schrittfolge im Incident

Eine praxistaugliche Vorgehensweise, die in vielen Umgebungen funktioniert:

• Schritt 1: Bestätigen Sie Latenz-Anstieg (p95/p99) und Scope (welche Services/Regionen/Nodes).
• Schritt 2: Prüfen Sie CPU pro Core und SoftIRQ; suchen Sie nach Hotspots statt Durchschnitt.
• Schritt 3: Prüfen Sie Drops: Interface, qdisc, Treiber; vergleichen Sie betroffene und unbetroffene Nodes.
• Schritt 4: Prüfen Sie Retransmissions: Anstieg spricht für Paketverlust oder extreme Queueing-Effekte.
• Schritt 5: Prüfen Sie Changes (Deployments, Config, Mesh, CNI, Kernel, iptables/nftables).
• Schritt 6: Mitigation priorisieren: Impact reduzieren (Traffic shiften, Rollback, Kapazität, Rate-Limits).

Diese Reihenfolge reduziert den typischen Fehler, zu früh tief in Logs zu gehen, obwohl das Problem hostnah (CPU/Netz) ist.

Mitigation-Muster: Was hilft typischerweise wirklich

Die richtigen Maßnahmen hängen davon ab, ob CPU die Ursache oder Folge ist. Trotzdem gibt es bewährte Muster, die häufig wirken:

• Kapazität/Scale-out: Mehr Nodes oder mehr CPU-Headroom reduziert ρ und damit Queueing-Latenz.
• IRQ-/RSS-Tuning: Bessere Verteilung von Netzwerkverarbeitung auf Cores; verhindert Hotspots.
• Conntrack/NAT reduzieren: Egress-Gateways, weniger SNAT, weniger Flow-Churn; entlastet CPU.
• Retry-Stürme bremsen: Circuit Breaking, Backoff, Rate Limiting; verhindert positive Rückkopplung.
• qdisc anpassen: Moderne Disziplinen wie fq_codel können Latency unter Load stabilisieren (je nach Umgebung).
• Sidecar-/Proxy-Last reduzieren: Filter, Logging, mTLS-Settings und Sampling/Telemetry-Overhead prüfen.
• Throttling vermeiden: CPU-Limits realistisch setzen; kritische Netzwerkkomponenten nicht drosseln.

Wenn Sie tiefer in TCP-Reaktionen auf Verlust und Congestion Control einsteigen möchten, ist die RFC-Basis ein guter Ausgangspunkt: RFC 9293 (TCP).

Spezialfall Kubernetes: Warum Node-CPU wichtiger ist als Pod-CPU

In Kubernetes wird häufig nur Pod-CPU betrachtet. Netzwerkprobleme entstehen aber oft im Node-Kontext: SoftIRQ, CNI, iptables/nftables, kube-proxy, Sidecar-Overhead und Treiber laufen außerhalb oder quer zu Containergrenzen. Dadurch kann ein Pod „nicht so hoch“ aussehen, während der Node saturiert ist – und genau dann entstehen Drops und Latenz. Zusätzlich können CPU-Limits zu CFS-Throttling führen: Der Pod hat Arbeit, darf aber nicht laufen. Das macht Netzverarbeitung indirekt langsamer, weil Userspace nicht schnell genug aus Sockets liest oder schreibt.

Ein robustes Dashboard sollte daher Node- und Pod-Sicht nebeneinander zeigen, inklusive Throttling-Indikatoren, um falsche Schlussfolgerungen zu vermeiden.

Outbound-Quellen für vertiefende Informationen

• Google SRE: Incident Response
• Google SRE: Monitoring Distributed Systems (Golden Signals)
• RFC 9293: Transmission Control Protocol (TCP)
• Linux tc(8): Traffic Control und Queueing
• Linux Kernel Networking Dokumentation

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.