- 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
- 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 profiling
CPU profiling is a form of dynamic program analysis that measures the time and frequency with which various functions or instructions are executed during the program's run. This is critical for optimizing code, identifying bottlenecks, and ensuring that an application scales efficiently. Use CPU profiling to optimize performance and to minimize latency or response time.
- Goals of CPU profiling
- Common problems and solutions
- How to control CPU profiling
- CPU tab
- Best practices
Goals of CPU profiling
1. Identify bottlenecks: To locate the sections of code where most of the CPU time is spent.
2. Improve efficiency: To refactor or optimize the inefficient parts of the code.
3. Analyze CPU utilization: To understand how the application uses CPU and to check if it is evenly distributed across cores and threads.
4. Optimize scalability: To ensure that the application can handle more tasks or users without degrading performance.
Common problems and solutions
High CPU usage
Problem: The application is consuming an excessive amount of CPU.
Solution: Profile your application to identify which methods or operations are consuming the most CPU time. Optimize the method or use more efficient algorithms or data structures.
Uneven multithreading
Problem: CPU usage is uneven across threads, leading to poor performance.
Solution: Look for thread synchronization issues, such as locks and semaphores that may be causing some threads to wait unnecessarily.
Infrequent but long-running operations
Problem: The application generally performs well but occasionally has spikes in CPU usage.
Solution #1: Estimate CPU usage by statistical profiling, it can give you valuable insights into the performance characteristics of your Java application.
Solution #2: Profile the application over an extended period and look for occasional methods or operations that are expensive in terms of CPU time. Optimize these parts of the code or offload them to a separate thread or process.
How to control CPU profiling
You can start and stop CPU profiling during the execution of your application as many times as you want. When CPU profiling is stopped, the overhead is negligible.
Profiler UI
When the profiler is connected to an application, the toolbar shows these CPU profiling controls:
| Toolbar button | Description |
|
Start/Stop CPU profiling. |
|
Clear recorded CPU profiling results and continue CPU profiling. |
Agent startup options
It may be useful to launch the application with CPU profiling right from the start using profiler agent startup options.
HTTP API
If you need remote control or automation in your profiling workflow, YourKit Java Profiler lets you manage CPU profiling using HTTP API endpoints:
Java API
The YourKit Java Profiler also provides a Java API
for deep integration with Java applications.
The com.yourkit.api.controller.v3.Controller
includes methods for starting,
stopping, and resetting the CPU profiling,
similar to the toolbar buttons.
Triggers
Profiler built-in triggers allow to start CPU profiling on high CPU usage, by timer, on entering particular method, or by other conditions.
CPU tab
The results of CPU profiling can be analyzed from different perspectives:
- Telemetry charts.
- Call tree - All threads - Displays methods organized into a single combined call tree across all threads.
- Call tree - By thread - Displays methods organized into separate call trees per thread.
- Flame graph - Displays called methods as a flame graph.
- Hot spots - Shows methods that consumed the most time.
- Method list - Provides a complete list of all called methods.
Best practices
Use sampling
Instead of tracing every method call, use sampling to collect data over a period to reduce the overhead of profiling.
Capture snapshot
Capture performance snapshot after collecting enough data. If you profile for too short a time, you might miss issues that only appear intermittently. On the other hand, profiling for too long may make it harder to sift through the data.
Focus on key CPU consumers
When analyzing profiling data, prioritize the functions or operations that consume the most CPU time. Focusing on these for optimization will yield the most significant performance gains.
Detect anomalies
Keep an eye out for unusual spikes or drops in CPU usage or other metrics that could indicate a problem. Investigate these anomalies to find root causes and to optimize accordingly.
Monitor telemetry charts
Continuously monitor telemetry charts that track key metrics like CPU usage, memory consumption, and thread activity. This practice can help you identify trends, anticipate issues, and make proper optimization decisions.
Profile in a production-like environment
Always profile in an environment that closely mimics the production setting.
Analyze and iterate
Profiling is not a one-time task. It's an iterative process that should be part of the development lifecycle.
Avoid premature optimization
Do not optimize without profiling data to back your changes. This might make the code more complex without any substantial gain in performance.
Compare before and after
Always compare the performance metrics before and after making optimizations to validate that they have the intended effect.