- 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 profiling modes
- CPU sampling
- CPU tracing
- Call counting
- Telemetry
- Call tree - All threads
- Call tree - By thread
- Flame graph
- CPU hot spots
- Method list
- Java EE profiling results
- Callee list view
- Method merged callees view
- Method back traces view
- CPU usage estimation
- What-if: an ability to ignore particular methods or focus on particular methods only
- Wall time and CPU time
- Thread profiling
- Virtual threads support
- Object allocation profiling
- Memory profiling
- Monitor profiling
- Exception profiling
- JFR (Java Flight Recorder)
- 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 sampling
How CPU sampling works
CPU sampling works by taking stack snapshots of the application's call stack to identify which functions are currently executing. Over time, a pattern emerges as certain functions are seen to be executing more frequently than others. The frequency with which a function appears in the sampled call stacks indicates its relative contribution to the total CPU time. By focusing on the functions that appear most often, developers can pinpoint performance bottlenecks.
It's important to note that CPU sampling doesn't capture every method invocation. This means that it can't provide an exact count of how many times a specific method was called. The data is statistical in nature and is meant to give an overall view of where the application spends most of its CPU time.
Advantages
- Lower performance overhead
- Easier data analysis
Disadvantages
- Less detailed than tracing
- May miss short-lived or rare events
Performance overhead
The performance impact of CPU sampling is generally low. It adds some overhead to the application, but the impact is often minimal because the sampling frequency is typically low. It is a lightweight method and is usually suitable for use in production environments. Please read this article if you want to learn more about how to reduce or avoid the impact of the profiler.
Use CPU sampling when you want a lightweight method to identify performance bottlenecks with minimal impact on the application. CPU sampling is suitable for use in production environments or when a high-level overview of the application's performance is sufficient.
Options
You can configure some CPU sampling aspects with the following options.
Measured time
Specify whether CPU or wall time will be measured for profiled methods.
Asynchronous sampling
Asynchronous sampling is a low overhead sampling mode that does not suffer from the Safepoint bias problem. It features HotSpot-specific APIs to collect stack traces, and with OpenJDK, Oracle JDK and other Java runtimes based on the HotSpot JVM. This mode is available only on Linux and macOS.
When measuring CPU time in async sampling mode, the profiler sets a timer which counts down against both user and system CPU time consumed by all threads in the process. As soon as the counter exceeds the CPU time threshold, the profiler collects the call stack in the thread which caused the timer expiration.
Sampling period
Interval between thread stack samples. Applies to the non-async sampling and async wall-time sampling.
Async CPU time threshold
CPU time a thread must accumulate before stack sampling is triggered. Applies to the async sampling when measuring CPU time.