 |
The following options are available:
- Auto-tuning settings
Here, you can disable auto-tuning.
Furthermore you can configure the criteria for determining an overhead hot spot. A method
is considered an overhead hot spot if both of the following conditions are met:
-
the total time of all its invocations exceeds a threshold in per mille of the entire total time
in the thread
-
its average time is lower than an absolute threshold in microseconds
- Time settings
Select whether you want times shown in the CPU view section to be
measured in
- elapsed time
With elapsed time selected, the clock time difference between
method entry and method exit will be shown. Note that if the
thread state selector is set to
its standard setting (Runnable). Waiting, blocking and Net IO thread states
are not included in the displayed times.
- estimated CPU time
With estimated CPU time selected, the CPU time used between
method entry and method exit will be shown. On Windows and Mac OS the
system supplies CPU times with a 10 ms resolution which are used to
calculate the estimated CPU times. On Linux and Solaris the VM does
not supply a CPU time and the estimated CPU times are roughly estimated
by looking at the number of runnable threads.
- Settings for exceptional method run recording
Exceptional method run recording has the
following configurable parameters:
- Maximum number of separately recorded method runs
The maximum number of the slowest invocations that are shown separately
in the call tree view.
Increasing this value can increase memory overhead and visual clutter in the call tree.
- Time type for determining exceptional method runs
The time measurement that is used for finding the slowest method invocations.
Note that this setting is not linked to the thread state selector in the
CPU views.
- Call tree splitting settings
Call tree splitting like URL splitting or
method splitting have the potential to create
very broad call trees that could use up all available memory. To prevent excessive memory usage,
call tree splitting is capped.
After the cap has been reached for a particular splitting type, further splits are consolidated
with a description of [capped nodes]. On that node, a hyperlink allows you to reset the cap counter.
In that case, new call tree splits will be recorded up to the currently configured cap.
|