# Perf & Flamegraphs: Den Code im Kernel sichtbar machen

TL;DR / Management Summary Wenn top und iostat nicht mehr ausreichen, um ein Performance-Rätsel zu lösen, müssen wir tiefer graben. perf ist das ultimative Analysewerkzeug, das direkt auf Hardware-Counter (PMU) und Kernel-Events zugreift. Mit Flamegraphs verwandeln wir tausende Zeilen kryptischer Profiling-Daten in eine intuitive Grafik, die uns sofort zeigt, welche Funktion im Code (oder Kernel) die meiste Zeit frisst. Wer diese Tools beherrscht, findet Performance-Bugs, die für andere unsichtbar bleiben.

# 1. Einführung & Architektur

Blick in die CPU.

Der Linux-Kernel nutzt das Performance Monitoring Unit (PMU) der CPU. Wir können Ereignisse wie “Cache Misses”, “Branch Mispredictions” oder einfach nur “CPU Zyklen” pro Funktion messen.

# Die Analyse-Pipeline (Mermaid)

graph TD
    A[Target: Slow Application / Kernel] --> B[perf record: Collect Data]
    B --> C[perf.data: Raw Event Storage]
    C -->|Option 1: Static| D[perf report: Text UI]
    C -->|Option 2: Visual| E[Stack Folding: perf script]
    E --> F[FlameGraph.pl: Generate SVG]
    F --> G[Visual Analysis: Wide boxes = High CPU]

# 2. Erste Schritte mit perf

Den Puls messen.

# Installation

sudo apt install linux-tools-common linux-tools-generic # Debian
sudo pacman -S perf # Arch

# CPU-Zyklen aufzeichnen

# Zeichne für 10 Sekunden alle Prozesse auf (-a: all, -g: call graph)
sudo perf record -a -g -- sleep 10

# Den Bericht lesen

sudo perf report
# Navigieren Sie durch die Liste. Die obersten Einträge verursachen die meiste Last.

# 3. Flamegraphs erstellen

Visualisierung von Komplexität.

Flamegraphs zeigen den Call-Stack. Die Breite eines Balkens entspricht der verbrauchten CPU-Zeit.

# Schritt-für-Schritt

1. Daten sammeln: perf record -a -g -F 99 -- sleep 30
2. Skripten: perf script > out.perf
3. Visualisieren (erfordert FlameGraph-Skripte von GitHub):

   ./stackcollapse-perf.pl out.perf > out.folded
   ./flamegraph.pl out.folded > performance.svg

4. Öffnen Sie performance.svg im Browser. Suchen Sie nach breiten “Berggipfeln” – das sind Ihre Flaschenhälse.

# 4. Day-2 Operations: Hardware-Zähler nutzen

Warum ist es langsam?

Es ist nicht immer die CPU-Logik. Oft wartet die CPU auf den RAM.

# Zeige Cache-Misses (Häufige Ursache für schlechte Performance)
sudo perf stat -e cache-misses,cache-references,instructions,cycles -p <PID>

# 5. Troubleshooting & “War Stories”

Wenn Symbole fehlen.

# Story 1: “Das [unknown] Rätsel”

Symptom: perf report zeigt nur Hexadezimal-Adressen oder den String [unknown] statt Funktionsnamen. Ursache: Die Applikation wurde ohne Debug-Symbole (Stripped) kompiliert oder es fehlen die debuginfo Pakete des Kernels. Lösung: Installieren Sie die passenden -dbgsym oder -debuginfo Pakete. Starten Sie Java-Apps mit dem perf-map-agent, um JIT-Methoden sichtbar zu machen.

# Story 2: “Der Overhead-Kill”

Symptom: Die Performance-Analyse macht das Problem noch schlimmer oder bringt den Server zum Absturz. Ursache: Die Sampling-Frequenz (-F) war zu hoch (z.B. 10.000 Hz). Der Kernel verbringt mehr Zeit mit dem Schreiben der Profiling-Daten als mit der Applikation. Lösung: Starten Sie mit niedrigen Frequenzen (z.B. -F 99) und tasten Sie sich vorsichtig heran.

# 6. Fazit & Empfehlung

• Pflicht: Nutzen Sie perf stat für einen schnellen Überblick über die Effizienz (Instructions per Cycle).
• Wahl: Nutzen Sie Flamegraphs für die Kommunikation mit Entwicklern – ein Bild sagt mehr als tausend Logs.
• Wartung: Halten Sie Ihre debuginfo Repositories bereit, damit Sie im Ernstfall sofort aussagekräftige Profile erstellen können.

# Anhang: Cheatsheet