- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- Solving performance problems
- CPU profiling
- Threads
- Deadlock detector
- Memory profiling
- Garbage collection
- Monitor profiling
- Exception profiling
- Probes: monitor events of various kinds
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler Java API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
- FAQ: How to profile in my scenario?
Threads
When you are connected to the profiled application, use the "Threads" tab to track the live threads.
The telemetry information is remembered in a circular buffer in the profiler agent memory. This allows you to connect to a profiled application on demand and discover how the application behaved in the past.
The buffer capacity is 1 hour by default,
and can be changed with the startup option telemetrylimit.
Please also consider the automatic deadlock detector
Start/stop stack telemetry
The thread stack and state telemetry information can be very useful because it allows you to connect to the profiled application on demand and discover how the application behaved in the past. In most cases, there is no significant overhead of collecting this information, and thus you do not need to stop it.
However, it makes sense to stop it in production Java servers in order to ensure minimum profiling overhead.
The telemetry is running by default, unless
disablestacktelemetry
startup option has been specified.
When you are connected to the profiled application, use corresponding toolbar button to start/stop the telemetry:
Threads in HPROF snapshots
For HPROF snapshot, "Threads" tab shows thread stacks at the moment of the snapshot capture (if available).
