- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Running applications with the profiler
- Connect to profiled application
- Troubleshoot connection problems
- Solving performance problems
- CPU profiling
- CPU usage estimation
- Sampling
- Asynchronous sampling
- Tracing
- Call counting
- CPU tab
- What-if: an ability to ignore particular methods or focus on particular methods only
- Comparing performance snapshots
- Sampling settings
- Tracing settings
- 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
- IDE integration
- 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?
CPU usage estimation
You can estimate CPU usage in given time range, basing on available stack trace telemetry. Profiler will show merged call tree for all the stacks (CPU samples) recorded within the specified time frame and will display number of the samples. The wider selected range is, i.e. the more samples are available, the better is the estimation.
How to invoke
Select arbitrary time range in a telemetry graph:
Comparison with CPU sampling
This feature is similar to CPU sampling, as it also uses sampling approach, but there are sufficient differences:
| Comparison criteria | CPU usage estimation | CPU sampling | Comments |
| Results availability | As long as stack telemetry is running | Should be explicitly started | CPU usage estimation is ideal for analysis of anomalies such as CPU spikes, especially those which has already happened, so you do not need to turn CPU sampling or tracing on and try reproduce the spike. |
| Accuracy | Lower | Higher |
CPU usage estimation is based on thread telemetry,
whose frequency is normally as low as 1 sample per second,
but can be changed using the startup option
CPU usage estimation can adequately measure events not shorter than the thread telemetry period. So, it suits for measuring events or method calls that last at least several seconds. If the measured event or method call is long enough, the estimation will do its job - locate problematic code responsible for the CPU spike.
For measuring shorter events or methods, use normal CPU profiling,
or decrease the telemetry period using the startup option
|
| Granularity | Results are available for each particular event, as well as for entire time range | Results are aggregated for entire period of CPU profiling |
CPU usage estimation enables analysis of particular events or time ranges within single snapshot. CPU profiling results are aggregated since CPU profiling has been started. It is not possible to "extract" CPU profiling results for a smaller time range within one snapshot. However, you can choose which method calls to analyze. |