Ein Flame Graph lesen: Breite bedeutet Samples, die x-Achse ist keine Zeit

Ziel

Herausfinden, wo ein laufendes Programm CPU-Zeit verbringt, indem ein Flame Graph korrekt gelesen wird, statt eine flache Funktionsliste zu durchsuchen und bei Aufrufern zu raten.

Voraussetzungen

Ein Sampling-Profiler, der Stack-Traces aufzeichnet (Linux perf, py-spy für Python, ein eigener Sampler der Laufzeitumgebung), die FlameGraph-Skripte oder ein Profiler, der das SVG direkt schreibt, Symbole und Unwinding-Informationen, damit Frames nicht [unknown] sind, sowie eine repräsentative Last während der Aufzeichnung.

Schritte

1. Unter Last aufzeichnen. Greggs Beispiel lautet perf record -F 99 -p PID -g -- sleep 30, danach perf script | stackcollapse-perf.pl > out.folded und flamegraph.pl out.folded > out.svg; ungerade Raten wie 99 Hz vermeiden, dass die Aufzeichnung im Gleichschritt mit anderer Aktivität läuft. Für Python schreibt py-spy record -o profile.svg --pid 12345 den Graphen direkt.
2. Die Achsen so lesen, wie sie die Flame-Graph-Seite definiert: Die x-Achse ist die alphabetisch sortierte Grundgesamtheit der Stack-Profile, nicht der Ablauf der Zeit; die y-Achse ist die Stack-Tiefe, unten bei null beginnend; jedes Rechteck ist ein Frame; je breiter es ist, desto häufiger erschien es in den Samples; die obere Kante zeigt, was auf der CPU lief, und alles darunter ist dessen Abstammung.
3. Nach breiten Plateaus entlang der oberen Kante suchen: Diese Funktionen liefen selbst und sind Kandidaten für schnellere Implementierungen.
4. Nach breiten Frames weiter unten suchen, deren Kinder viele schmale Türme sind: Die Zeit verteilt sich auf die aufgerufenen Funktionen, also ist der Aufrufer die Stelle für eine Änderung (seltener aufrufen, bündeln, cachen).
5. Die Suche des SVG verwenden, um die Breite einer Funktion über alle Stacks hinweg zu summieren; eine von vielen Stellen aus aufgerufene Funktion zeigt sich als schmale Türme, die sich addieren.
6. Zwei Profile (vorher und nachher, oder ein langsamer und ein gesunder Host) mit einem differenziellen Flame Graph vergleichen, der jeden Frame nach der Änderung zwischen den beiden Profilen einfärbt.
7. Die Anzahl Samples prüfen, bevor kleinen Breiten Glauben geschenkt wird: Dreissig Sekunden bei 99 Hz ergeben rechnerisch etwa 2970 Samples pro CPU, sodass ein Frame mit 1 % Breite auf rund 30 Samples beruht und Bruchteile eines Prozents Rauschen sind.
8. Ist das Programm langsam, während die CPU untätig ist, zeigt ein CPU-Flame-Graph nichts Nützliches; stattdessen ein Off-CPU-Profil des Wartens aufzeichnen.

Erwartetes Ergebnis

Eine benannte Funktion oder ein Aufrufpfad mit ihrem Anteil an den Samples, das Profil abgelegt neben der Änderung, die es adressiert, sowie ein zweites Profil, das die verringerte Breite zeigt.

Grenzen und Prüfbasis

Fehlende Frame-Pointer oder aggressives Inlining stutzen oder verschmelzen Frames. Sampling ordnet Zeit der gerade laufenden Instruktion zu, nicht ihrer Ursache; ein Cache-Miss erscheint als die Instruktion, die dadurch blockierte. Interpretierte und JIT-kompilierte Sprachen brauchen eigene Stack-Walker. Basierend auf den zitierten Seiten; es werden keine Messungen behauptet.