Hohe CPU-Load durch Kernel-Threads und irq/softirq analysieren: Atop & perf Praxishandbuch

Hohe CPU-Load durch Kernel-Threads und irq/softirq ist ein klassisches Betriebsproblem: Monitoring zeigt steigende Load Averages und träge Services, aber in top oder htop findet sich kein klarer Prozessverursacher. In solchen Fällen läuft Arbeit im Kernel (Kernel‑Threads) oder als Interrupt-/SoftIRQ‑Verarbeitung. Dieses Runbook beschreibt, wie Sie mit atop die Zeitachse und mit perf sowie eBPF die Kernelpfade analysieren, typische Ursachen einordnen, Maßnahmen ableiten und sichere Rückfallstrategien planen.

Begriffe kurz erklärt

Eine kurze Begriffsabstimmung verhindert Fehlinterpretation:

• Load Average: Misst die durchschnittliche Zahl an Threads, die laufen oder auf CPU/I/O warten. Ein hoher Load heißt nicht automatisch volle CPU‑Auslastung; es kann auch I/O‑Wartezeit oder Blockierung sein.
• CPU-Anteile: user (Anwendungsprozesse), system (Kernelarbeit), irq (Hardware-Interrupts), softirq (Software-Interrupts, also Nachbearbeitung), iowait (Warten auf Storage I/O) – diese Aufteilung ist wichtig für die Ursachenanalyse.
• Kernel-Threads: Prozesse im Kernel‑Kontext wie kworker/* oder ksoftirqd/*. Sie führen Kernelarbeit aus und erscheinen in Prozesslisten, sind aber nicht „User‑CPU“.
• IRQ / SoftIRQ: IRQ sind hardwaregesteuerte Unterbrechungen (Interrupts); SoftIRQs (Software‑Interrupts) sind ihre Verarbeitung im Software‑Kontext, häufig für Netzwerk- und I/O‑Stacks (z. B. NAPI für Netzwerke).

Voraussetzungen und Sicherheitsrahmen

Analysen benötigen oft Root-Rechte und können selbst Last erzeugen. Planen Sie:

• Abstimmung mit Security/Change‑Management, insbesondere bei perf oder eBPF.
• Kurze Messfenster (z. B. 10–60 Sekunden) und passive Logsicherung vor Änderungen.
• Rollback‑ und Dokumentationspfad für sysctl‑Änderungen, systemd‑Units oder Treiberflags.

Erste Kurzdiagnose (5 Minuten)

Diese Sequenz ordnet schnell ein, ob IRQ/SoftIRQ, I/O oder VMM‑Stealing die Ursache sind.

uptime
mpstat -P ALL 1 5
top -H -b -n 1 | head -n 80

Interpretation: Wenn mpstat erhöhte Werte in irq/soft zeigt und top Threads wie ksoftirqd/N oder kworker listet, ist Kernel‑/Interrupt‑Verarbeitung wahrscheinlich. Steal deutet auf Hypervisor‑Ressourcenkonflikte hin.

Atop als Zeitachsenwerkzeug

atop zeichnet historische Metriken persistenter als top und ordnet CPU‑Breakdown über Zeit. Idealerweise existieren bereits Logdateien; sonst beobachten Sie live.

# Live-Überwachung
atop 1

# Historische Datei lesen (Beispiel)
atop -r /var/log/atop/atop_20260728 -b 10:00 -e 10:30

Worauf achten: zeitliche Korrelation zwischen Netz- oder Storage‑Spitzen und steigender softirq/irq‑Zeit, stabile vs. sporadische Muster und welche Kernel‑Threads am aktivsten sind.

Fokus: perf für Kernelpfade

perf zeigt auf Funktions‑ und Symbol‑Ebene, wo CPU‑Zeit im Kernel verbrannt wird – etwa im Netzwerkstack (napi, skb), Block‑I/O (nvme, block), oder Netfilter/conntrack. In Containern oder bei fehlenden Debug‑Symbolen sind die Ergebnisse eingeschränkt.

Vorbereitung und sichere Nutzung

# Prüfen von Restriktionen
sysctl kernel.perf_event_paranoid
sysctl kernel.kptr_restrict
perf --version || true

Wenn kernel.perf_event_paranoid > 1 gesetzt ist, kann perf eingeschränkt sein. Änderungen sollten mit Security abgestimmt werden. Beginnen Sie ohne Callgraphs (-g), um Overhead gering zu halten.

Kurzprofil und Reporting

# Kurzüberblick (interaktiv, geringerer Overhead)
sudo perf top

# Konservatives Recording: 30s, Sampling-Frequenz 99Hz
sudo perf record -a -F 99 -- sleep 30
sudo perf report --stdio

Lesen Sie die Ergebnisse nach Hotspots: Namen wie napi_poll, __netif_receive_skb_core, xfrm_output oder nf_conntrack_* weisen auf Netzwerk/Netfilter; block_rq_issue, nvme_submit_io auf Storage.

Vertiefte perf-Analyse und Artefakte

Wenn das erste Recording Hinweise liefert, erweitern Sie gezielt. Callgraphs (-g) bringen Kontext, erhöhen aber Sampling-Overhead; nutzen Sie sie mit Bedacht.

# Callgraph nur wenn nötig, kurze Dauer
sudo perf record -a -F 249 -g -- sleep 15
sudo perf script > perf.raw
# Optional: FlameGraph-Erzeugung (auf Admin-Workstation)
# git clone https://github.com/brendangregg/FlameGraph.git
# ./FlameGraph/stackcollapse-perf.pl perf.raw > out.folded
# ./FlameGraph/flamegraph.pl out.folded > perf.svg

Warum das funktioniert: Sampling‑Profiler sammeln Stacktraces der aktuell laufenden Ausführung; aggregierte Stacks zeigen dominante Pfade. Wann es scheitert: bei sehr kurzer Last oder Sampling‑Konfiguration, die System‑Call‑signaturen verschluckt (z. B. fehlende Symbole).

eBPF und Tracepoints für punktgenaue Fragen

eBPF (Extended Berkeley Packet Filter) erlaubt niedrig‑latenz‑Tracing im Kernel. Für Produktivsysteme ist bpftrace eine gute Wahl für kurzfristige Hypothesentests; bpftool hilft bei Metriken. Auch hier gilt: Abstimmung mit Security und kurze Laufzeiten.

# Beispiel: Zähle Aufrufe von ksoftirqd-Handlern (bpftrace)
sudo bpftrace -e 'tracepoint:irq:softirq_entry { @[comm] = count(); }' -c 'sleep 10'

# Alternativ: Trace network napi poll duration
sudo bpftrace -e 'kprobe:napi_poll { @[comm] = hist(nsecs); }' -c 'sleep 10'

Warum nutzen: eBPF misst feingranular ohne massive Overhead, ideal um zu prüfen, ob z. B. napi_poll lange läuft. Wann es versagt: ältere Kernel ohne BPF‑Unterstützung oder Restriktionen durch Distributions‑Policies.

Häufige Ursachen, Prüfpfade und konkrete Kommandos

1) Netzwerk: PPS, Offload, CNI/Overlay

Viele kleine Pakete (hoher Packets-per-Second, PPS) treiben SoftIRQs. Prüfen Sie Drops, Errors, Offloads (TSO/GSO/GRO) und CNI‑Kapselung.

ip -s link show dev eth0
ethtool -k eth0
ethtool -S eth0 | sed -n '1,200p'
# RPS (Receive Packet Steering) prüfen und setzen
cat /proc/sys/net/core/rps_sock_flow_entries
# Beispiel: RPS für rx-queues setzen (Queue anpassen)
echo 32768 | sudo tee /sys/class/net/eth0/queues/rx-0/rps_cpus

Hinweis: RPS/RFS versucht Verarbeitung auf mehrere CPUs zu verteilen. Wenn falsch gesetzt, kann es Cache‑Locality verletzen und Latenzen erhöhen.

2) irqbalance und CPU-Affinität

irqbalance verteilt Interrupts. Bei isolierten CPUs oder NUMA kann das suboptimal sein. Prüfen Sie smp_affinity pro IRQ.

sudo systemctl status irqbalance --no-pager
# Beispiel: IRQ-Affinity anzeigen
awk 'NR>1{print $1}' /proc/interrupts | head -n 5 | sed 's/://g' | while read irq; do
  echo "IRQ $irq:"; cat /proc/irq/$irq/smp_affinity_list 2>/dev/null || true
done

Wenn ein IRQ auf einer einzelnen CPU dominiert, kann gezieltes Pinning Entlastung bringen. Risiko: Falsches Pinning verschlechtert Durchsatz oder Latenz – immer messen.

3) Storage: Completion Storms, Treiberfehler

Viele kurze I/Os, Timeouts oder Treiberwarnungen führen zu kworker‑Aktivität.

iostat -x 1 5
nvme list 2>/dev/null || true
dmesg -T | tail -n 200

Treiberfehler in dmesg oder Kernel‑OOPS sind kritische Indikatoren; hier ist oft ein Treiberupdate oder Kernel‑Rollback nötig.

Kubernetes: Node‑vs‑Pod‑Unterscheidung und Checks

In Kubernetes sind häufige Ursachen: Pod mit hoher PPS, kube-proxy NAT/conntrack, CNI‑Overlay oder CSI‑Treiberverhalten. Wichtige Schritte:

kubectl get nodes -o wide
kubectl top nodes
kubectl top pods -A --sort-by=cpu | head -n 30
# Auf dem Node: conntrack-Zähler prüfen
sudo sysctl net.netfilter.nf_conntrack_count
# CNI: prüfen, ob Overlay (vxlan/geneve) läuft
ip link show | grep vxlan -A 2 || true

Tipp: Ein einzelner Pod kann hohe Node-SoftIRQ verursachen ohne selbst viel User‑CPU anzuzeigen. Nutzen Sie DaemonSet‑Diagnoserunner für Nodelevel‑Profiling, nicht nur kubectl top.

Metriken, Dashboards und Retention

Damit Diagnose wiederholt werden kann, sammeln Sie diese Metriken dauerhaft (Prometheus/Grafana oder ähnliche): per‑CPU irq/softirq, NET_RX/NET_TX Zähler, PPS, rx_errors/drops, iowait, kworker/ksoftirqd Thread Counts, conntrack size. Sorgen Sie für ausreichend Retention (z. B. 7–30 Tage), um Regressionen nach Kernel‑Updates zu erkennen.

Praxis-Checkliste: Minimaler Prüfpfad

1. Sichern: uptime, uname -a, dmesg, /proc/interrupts, /proc/softirqs.
2. Schnellcheck: mpstat, top -H, ip -s link, ethtool -S, iostat.
3. Atop: zeitliche Korrelation identifizieren.
4. Perf (konservativ): kurze Aufnahme, initial ohne -g.
5. eBPF für Hypothesentests: bpftrace kurze Scripte.
6. Änderungen schrittweise: Offloads, RPS, irqbalance, Pinning – jeweils messen.
7. Rollback planen und dokumentieren.

Wann einfache Maßnahmen nicht helfen

Es gibt Fälle, in denen einfache Tuning‑Maßnahmen versagen und tiefere Eingriffe nötig sind:

• Kernel‑ oder Treiberbug: dmesg oder perf zeigen Kernelpfade, die nur durch Patch/Rollback lösbar sind.
• Hardware‑Offload Inkompatibilität in Virtualisierung: Offloads deaktivieren und testen.
• Architekturbedingte Limits: z. B. massive NAT/conntrack Last erfordert Architekturänderung (LoadBalancer statt NodePort/SNAT).

Rückfall- und Kommunikationsstrategie

Kommunikation ist entscheidend: Bei Änderungen informieren Sie SRE/Stakeholder, planen Wartungsfenster wenn nötig und halten Metriken vor/nach fest. Bewährte Praxis:

• Änderungen einzeln und mit Zeitstempel dokumentieren (Changelog auf System).
• Automatisierte Messjobs vor/nach (mpstat, /proc/interrupts, atop-Intervalle).
• Im Kubernetes‑Kontext: cordon/drain eines Testnodes, dann Änderung und Messung mit Lastsimulation.

Fazit

Hohe Kernel‑ oder irq/softirq‑Last ist oft schwer zu fassen, weil die Arbeit im Kernel statt in User‑Prozessen stattfindet. Ein methodischer Ansatz mit schneller Grobanalyse (mpstat/top/atop), gezieltem Profiling (perf) und punktgenauem Tracing (eBPF) liefert belastbare Hypothesen. Messen, ändern, zurückrollen: das ist die Reihenfolge. In Kubernetes ist die Unterscheidung zwischen Pod‑ und Node‑Verursacher besonders wichtig; eine falsche Maßnahme kann sonst Cluster‑weit Wirkung entfalten.

Dieses Runbook liefert die Werkzeuge und Prüfpfade, mit denen Administratoren, System Engineers und Operatoren fundiert analysieren, sicher testen und Änderungen verantwortet zurückrollen können.

Hohe CPU-Load durch Kernel-Threads und irq/softirq — Betriebs- und Architekturmaßnahmen

Neben der akuten Analyse sind nachhaltige Betriebs- und Architekturmaßnahmen entscheidend, damit das Problem nicht wiederkehrt. Treffen Sie Entscheidungen nicht nur auf Basis eines einzelnen Profils: Entwickeln Sie permanente Detektions‑, Test‑ und Rollback‑Pfade, die in Change‑Prozesse und Automatisierung passen.

Kontinuierliche Detektion und Alerting

Ein kurzfristiger Perf‑Snapshot hilft nur einmal. Legen Sie Alerts an, die SoftIRQ‑Veränderungen per CPU und PPS‑Anstieg erkennen und nach Regressionen in Kernel‑ oder CNI‑Komponenten alarmieren. Beispiel für eine einfache Prometheus‑Rule:

- alert: HighSoftirqPerCpu
  expr: increase(node_softirq_total[5m]) / count(node_cpu_seconds_total{mode="system"}) > 1000
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "Erhöhter SoftIRQ-Anteil auf {{ $labels.instance }}"

Wichtig: Regeln auf Ihre Baselines kalibrieren, um False‑Positives bei saisonaler Last zu vermeiden.

Canary‑Änderungen und Rollout‑Strategie

Änderungen an sysctl, IRQ‑Pinning oder Offloads sollten canaryartig auf wenigen Nodes getestet werden. Praxisablauf:

• Node cordon/drain eines Testnodes.
• Änderung mit Versionskontrolliertem sysctl‑Drop‑in.
• Automatisierte Messungen (5–15 Minuten) gegen Baseline.
• Rollback bei Verschlechterung.

Beispiel sysctl Drop‑in:

# /etc/sysctl.d/99-softirq-tuning.conf
net.core.default_qdisc = fq
net.core.rps_sock_flow_entries = 32768
net.ipv4.conf.all.rp_filter = 1

Automatisierung und Runbook‑Integration

Integrieren Sie Prüfskripte in Ihre Automatisierung (Ansible, Salt, Terraform für Cloud‑Instances) und versionieren Sie sysctl/irqbalance configs im Git. Ein Runbook‑Trigger sollte nach Kernel‑Updates automatisch kurzprofilen und einen Health‑Report in Ihren Ticketing‑Flow schreiben. So vermeiden Sie Überraschungen nach Patches.

Architekturmaßnahmen: Last verlagern, nicht nur patchen

Manche SoftIRQ‑Probleme lassen sich nicht mit Tuning lösen; hier sind architektonische Schritte effektiver:

• Reduzieren Sie PPS auf Node‑Ebene durch L4/L7‑LoadBalancer statt SNAT/NodePort, um conntrack‑Pressure zu vermeiden.
• Batching und Keep‑Alive in individueller Unternehmenssoftware reduzieren Paketanzahl; prüfen Sie socket‑Optionen (TCP_CORK, sendmmsg) in hoher PPS‑Last.
• Offloading‑Strategien mit Cloud‑ oder NIC‑Vendor abstimmen: HW‑Offload kann Last verschieben, aber auch Treiberinkompatibilitäten offenbaren.

Risiken, Vendor‑Koordination und Audit‑Artefakte

Sammeln Sie standardisiert Befunde (perf raw, flamegraphs, atop‑Schnappschüsse, tcpdump‑pcap mit Zeitstempeln), bevor Sie Vendor‑Tickets eröffnen. Ohne reproduzierbare Artefakte verlängert sich die Diagnose. Bei Kernel‑/Treiberfragen planen Sie gestaffelte Kernel‑Rollouts und behalten Boot‑Entrys (GRUB) für schnellen Revert.

Kurz: Setzen Sie auf Monitoring‑Hygiene, versionierte Konfigurationen, canary‑Rollouts und Architekturprüfung. So wird die Reaktion auf hohe Kernel‑ oder irq/softirq‑Last planbar, messbar und reversibel — im Einklang mit bestehenden Change‑ und Security‑Prozessen für Ihre digitalen Unternehmenslösungen.

Für dieses Thema sind auch Atop Analyse und Perf Cpu Profiling wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.