- System requirements
- Profiler architecture
- Profiler installation
- Uninstall profiler
- Running the profiler
- Profiler activation
- Welcome screen
- Start profiling
- Profiling overhead
- Snapshots
- Solving performance problems
- CPU profiling
- CPU and wall times when profiling Java applications
- CPU profiling modes
- CPU usage estimation
- CPU sampling
- Asynchronous CPU sampling
- CPU sampling settings
- CPU tracing
- CPU tracing settings
- Call counting
- CPU tab
- What-if: an ability to ignore particular methods or focus on particular methods only
- Thread profiling
- Virtual threads support
- Deadlock detector
- Memory profiling
- Garbage collection
- Monitor profiling
- Exception profiling
- Telemetry
- Probes: monitor events of various kinds
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Automatic deobfuscation
- Summary
- Filters
- Profiler command line
- Export of profiling results to external formats
- Profiler Java API
- Profiler HTTP API
- Settings
- Troubleshooting and FAQ
CPU usage estimation
YourKit Java Profiler collects stack samples of running Java threads at regular intervals. It allows you to analyze the frequency of function calls and their relationships, and to get an understanding of the performance of your Java program. We call it "statistical profiling".
Keep in mind that statistical profiling is an estimation, and the results may not be precise. However, it can give you valuable insights into the performance characteristics of your Java application. Also, remember that the quality of the estimation depends on the number of selected samples. The wider the selection, the more samples it contains, the better the estimate.
How to invoke
To estimate CPU usage, please select arbitrary time range in any telemetry chart. Profiler will show merged call tree for all the stacks (CPU samples) recorded within the selected time interval, and will display number of the samples:
Comparison with CPU sampling
This feature is similar to CPU sampling, as it also uses sampling approach, but there are sufficient differences:
| Criteria | CPU usage estimation | CPU sampling | Comments |
| Results availability | As long as stack telemetry is turned on | CPU sampling 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 to reproduce the spike. |
| Accuracy | Lower | Higher |
CPU usage estimation is based on stack 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 stack 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 the selected time interval | Results are aggregated for the 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. |