# perf: Die CPU-Performance unter dem Mikroskop

TL;DR / Management Summary perf ist das Standardwerkzeug für Performance-Profiling unter Linux. Es nutzt Hardware-Performance-Counter (PMU) der CPU und Kernel-Tracepoints, um statistisch zu erfassen, wo ein System Zeit verbringt. Ob Sie herausfinden wollen, warum ein Prozess 100% CPU last verursacht, oder warum Cache-Misses die Datenbank bremsen: perf liefert die Antwort mit minimalem Overhead.

# 1. Einführung & Architektur

Messen durch Stichproben (Sampling).

Anstatt jeden Befehl zu loggen (hoher Overhead), macht perf Sampling. Es schaut z.B. 1000 Mal pro Sekunde nach, welcher Code-Befehl gerade auf der CPU ausgeführt wird.

# Was kann perf messen?

# 2. perf in der Praxis

Die drei Säulen der Analyse.

# 1. Detaillierte Live-Statistik (perf stat)

Ideal für einen schnellen Überblick über die Effizienz eines Befehls.

perf stat -B dd if=/dev/zero of=/dev/null count=1000000

Achten Sie auf ‘Instructions per cycle’ (IPC). Ein Wert < 1.0 deutet oft auf Memory-Bottlenecks hin.

# 2. Live-Top-View (perf top)

Wie top, aber für Funktionen (Kernel und User-Space).

# Zeigt die heißesten Funktionen systemweit
perf top

# 3. Record & Report (perf record)

Für die detaillierte Analyse im Nachgang.

# 10 Sekunden lang das gesamte System sampeln
perf record -a -g -- sleep 10
# Ergebnis betrachten
perf report

# 3. Deep Dive: Flame Graphs

Den Wald vor lauter Bäumen sehen.

Ein perf report kann bei komplexen Applikationen tausende Zeilen lang sein. Flame Graphs (von Brendan Gregg) visualisieren diese Daten.

# Erstellung (Konzept)

  1. Daten sammeln: perf record -F 99 -a -g -- sleep 60
  2. Daten kollabieren: perf script | ./stackcollapse-perf.pl > out.folded
  3. SVG erstellen: ./flamegraph.pl out.folded > graph.svg

In einem Flame Graph ist die Breite eines Balkens proportional zur verbrauchten CPU-Zeit. Suchen Sie nach den “Plateaus”.

# 4. Day-2 Operations: Cache & Memory Tuning

Wenn die CPU auf den RAM wartet.

# Cache-Misses finden

Wenn eine CPU auf Daten aus dem RAM warten muss (L3 Cache Miss), verliert sie hunderte Zyklen.

perf stat -e cache-misses,cache-references,instructions,cycles ./my_app

Wenn die Miss-Rate hoch ist, müssen Sie die Datenstrukturen in Ihrer Applikation optimieren (Data Locality).

# 5. Troubleshooting & “War Stories”

Wenn perf nichts sieht.

# Top 3 Herausforderungen

  1. Symptom: perf report zeigt nur Hex-Adressen (0xffffffff81...) statt Funktionsnamen.

    • Ursache: Fehlende Debug-Symbole oder Kernel-KASLR.
    • Lösung: yum install kernel-debuginfo oder echo 0 > /proc/sys/kernel/kptr_restrict.

  2. Symptom: Flame Graphs zeigen nur “Unknown” oder flache Stacks.

    • Ursache: Programme wurden ohne Frame-Pointer (-fno-omit-frame-pointer) kompiliert.
    • Lösung: Applikation mit Frame-Pointern neu kompilieren oder perf record --call-graph dwarf nutzen (höherer Overhead).

  3. Symptom: perf record bricht ab (Permission denied).

    • Lösung: sysctl -w kernel.perf_event_paranoid=1 (erlaubt Usern mehr Rechte).

# “War Story”: Die gierige Spinlock

Ein High-Performance Proxy skalierte nicht über 4 Kerne hinaus. Jede zusätzliche CPU machte das System langsamer. perf top zeigte, dass 40% der Zeit in native_queued_spin_lock_slowpath verbracht wurde. Entdeckung: Alle Threads versuchten gleichzeitig, eine einzige globale Statistik-Variable zu aktualisieren. Durch den Wechsel auf thread-lokale Counter (Per-CPU Variables) verschwand der Lock-Contention und der Durchsatz verfünffachte sich.

# 6. Monitoring Integration

Profiling im Cluster.

# eBPF Exporter

Sie können eBPF-Programme nutzen, um perf-ähnliche Daten (wie Latenz-Histogramme) permanent zu sammeln und an Prometheus zu senden, ohne die CPU-Last von perf record zu haben.

# 7. Fazit & Empfehlung

perf ist die ultimative Wahrheit über CPU-Aktivität.

# Anhang: Cheatsheet

Aufgabe Befehl
Schneller Check perf stat <command>
Wer braucht CPU? perf top
Mit Stack-Trace perf record -g
I/O Latenz perf record -e block:block_rq_issue
Context Switches perf stat -e context-switches

# Referenzen