async-profiler - Low-Overhead JVM Profiler Cheatsheet
async-profiler ist ein Low-Overhead Sampling Profiler für die JVM. Traditionelle Java Profiler samplen nur bei Safepoints, was Ergebnisse zu großartig macht, was Code zu einer Safepoint mit sich bringt und die reale Hot Path verbergen kann. async-profiler nutzt AsyncGetCallTrace plus Perf Events zum Samplen überall, inkludierend Native Code und Kernel Frames, gebend ein viel ehrlicheres Bild. Es profiled CPU, Allocations, Lock Contention und mehr und exporte Flame Graphs oder JFR.
Installation
| Methode | Wie |
|---|
| Download | Get das Release Tarball für deine Platform |
| Extract | tar xzf async-profiler-*.tar.gz |
| Run | ./bin/asprof <pid> (neuer) oder ./profiler.sh <pid> |
| Permissions | kann sysctl kernel.perf_event_paranoid=1 und kernel.kptr_restrict=0 benötigen |
| Verifikation | ./bin/asprof --version |
Basis-Profiling
| Befehl | Beschreibung |
|---|
asprof -d 30 -f out.html <pid> | Profile 30s → Flame Graph |
asprof -e alloc -d 30 -f alloc.html <pid> | Allocation Profiling |
asprof -e lock -d 30 -f lock.html <pid> | Lock Contention |
asprof -e wall -d 30 -f wall.html <pid> | Wall-Clock (inkludiert Warten) |
asprof start <pid> / asprof stop -f out.html <pid> | Manual Start/Stop |
jps | Finde die JVM PID |
Event-Typen
| Event | Misst |
|---|
cpu | CPU-Zeit (Standard) |
alloc | Heap Allocations nach Stack |
lock | Lock/Monitor Contention |
wall | Wall-Clock inkludierend Blocked Time |
itimer | Fallback wenn Perf nicht verfügbar ist |
cache-misses, page-faults | Hardware/Software Perf Events |
# Wo verbringt die App tatsächlich Wall-Clock-Zeit (inkl. IO Waits)?
./bin/asprof -e wall -t -d 30 -f wall.html <pid>
| Flag | Produces |
|---|
-f out.html | Interactive Flame Graph |
-o collapsed | Folded Stacks (für FlameGraph Tooling) |
-o tree | Call Tree |
-o flat | Flat Hot-Method List |
-f out.jfr | JFR Recording (open in JMC) |
-t | Split nach Thread |
Launching Mit dem Agent
# Profile von JVM Startup (captures Warmup)
java -agentpath:/path/libasyncProfiler.so=start,event=cpu,file=profile.html \
-jar app.jar
| Agent-Option | Zweck |
|---|
start | Begin sofort |
event=cpu|alloc|lock | Was zu samplen ist |
file=NAME | Output Path |
interval=10ms | Sampling Interval |
jfr | Emit JFR-Format |
Lesen der Flame Graph
| Feature | Bedeutung |
|---|
| Breite | Share von Samples (Zeit) — Breiter ist Heißer |
| Höhe | Stack-Tiefe, nicht Kosten |
| Farben | Java (Grün), Native (Gelblich), Kernel (Orange) |
| Click | Zoom in eine Subtree |
| Search | Highlight Matching Frames |
Look für Wide Plateaus — ein Single Frame, der einen großen Horizontal-Share konsumiert, ist dein Hot Spot. Mixed Java/Native/Kernel Frames sind genau das, was Safepoint-Biased Profiler verbergen.
Common Workflows
# 1) CPU Hotspots in einem Running Service
./bin/asprof -d 60 -f cpu.html $(jps | grep MyApp | cut -d' ' -f1)
# 2) Chasing GC Pressure — wer allocates den meisten?
./bin/asprof -e alloc -d 60 -f alloc.html <pid>
# 3) Threads schauen Idle aber Latency ist Hoch → Wall-Clock
./bin/asprof -e wall -t -d 30 -f wall.html <pid>
# 4) Contention auf einer Shared Resource
./bin/asprof -e lock -d 30 -f lock.html <pid>
async-profiler vs Alternativen
| Aspekt | Async-Profiler | JFR | VisualVM |
|---|
| Safepoint Bias | Vermieden | Reduziert | Anwesend |
| Native/Kernel Frames | Ja | Begrenzt | Nein |
| Overhead | Sehr Niedrig | Niedrig | Höher |
| Allocation Profiling | Ja | Ja | Basis |
| Am besten für | Accurate JVM Hotspots | Built-in Continuous Recording | Quick GUI Inspection |
Das JVM-Pendant zu perf + FlameGraph für Native Code.
Ressourcen
