- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- IDE integration
- Profile .NET executable
- Profile ASP.NET application IIS
- Profile all .NET processes that will start
- Attach profiler to a running application
- Profile remote applications
- Profiling in Docker container
- Manually enable profiling of local applications
- Startup options
- Connect to profiled application
- Profiling troubleshooting
- Profiling overhead: how to reduce or avoid
- Capturing snapshots
- Solving performance problems
- CPU profiling
- Threads
- Memory profiling
- Garbage collection
- Exception profiling
- Probes: monitor higher level events
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
Startup options
The startup options allow to customize some aspects of profiling. These options can be configured when you start the profiled application.
When should I specify the startup options?
In most cases, you do not have to specify any of these options, except for those explicitly presented in the Profile action dialogs, because default behavior suits fine in most cases.
How can I specify the startup options?
These options can be configured when you start the profiled application:
- dialogs shown for the Profile... actions on the Welcome screen have "Advanced startup options..."
- when enabling profiling with the command line tool
-
if you enable profiling manually, there are following possibilities:
-
Value of environment variable
YNP_STARTUP_OPTIONS
-
Value of registry key
HKEY_LOCAL_MACHINE\SOFTWARE\YNP\STARTUP_OPTIONS
The environment variable's priority is higher than that of the registry key, if both are specified.
-
Value of environment variable
The options are comma-separated if you specify more than one option.
Environment variable substitution
It is possible to use environment variables in the startup options
with the ${VARIABLE}
syntax.
Substitutions are helpful for options which are not known until execution time.
If an environment variable is not set, it will be replaced with an empty string.
For example, if environment variable SNAPSHOT_DIR
is set to /tmp/snapshots
,
then startup option dir=${SNAPSHOT_DIR}
evaluates to
dir=/tmp/snapshots
.
Options file
If you need to specify a lot of agent options, or use same options for multiple projects
you may find useful options_file
option.
In options file you can specify agent options as usual, but also separate them line by line without commas.
Comment lines are denoted by the #
as the first non-blank character,
in which all remaining text on that line is ignored.
And of course you can use environment variables in options file too.
Options file example:
# Start with CPU profiling:
sampling
# Start with object allocation recording:
alloceach=100,allocsizelimit=4096
# Snapshot directory is specified via environment variable:
dir=${SNAPSHOT_DIR}
Description of the startup options
Networking options |
|
or
|
Specify the port that the profiler agent listens on for communication with the Profiler. By default, the port is chosen automatically: if port 10001 is free, it is used; otherwise, if port 10002 is free, it is used etc. If no port in the range 10001..10010 is free, an arbitrary free port is used. If port range is specified, profiler will choose first free port in the range. |
listen= <option>
|
Specify the profiler agent connectivity option.
|
ssl_certificate= <path to SSL certificate>
|
File with the SSL certificate in the PEM format. If intermediate certificates should be specified in addition to a primary certificate, they should be specified in the same file in the following order: the primary certificate comes first, then the intermediate certificates.
If the |
ssl_certificate_key= <path to secret key>
|
File with the secret key in the PEM format. |
ssl_password_file= <path to password file>
|
If the secret key |
YourKit Connection Broker options |
|
broker_url= <url>
|
Connection broker URL. |
broker_token= <token>
|
Connection broker access token. |
Main optionsThese options can be switched on startup only, i.e. corresponding behavior cannot be altered during runtime. |
|
or
|
Specify a path to the options file with agent startup options. Options from the options file will be used as if they were directly specified in its place, in order they are written in the file.
Example:
|
telemetrylimit= <hours> |
The telemetry information is remembered in a circular buffer in the profiler agent memory. This allows you to connect to a profiled application on demand and discover how the application behaved in the past. By default, the telemetry buffer is limited to store approximately 1 hour of recent telemetry data.
With the help of the Do not use unnecessarily long buffers Extending the telemetry buffer will allocate additional amount of memory in the profiled application's address space. That is especially important for 32-bit processes because their address space is limited. Also, the longer the buffer, the more time it takes to retrieve the telemetry information from the profiler agent when you connect to a long running profiled application. |
telemetryperiod= <milliseconds> |
Specify how often telemetry information is obtained. By default, the period is 1 second (1000 milliseconds). Note that setting smaller period can add overhead. |
probetablelengthlimit= <rows> |
Probes: limit the number of rows to be stored by the profiler agent per table. |
deadthreadlimit= <threads> |
Specify the number of recently finished threads for which
profiling results are kept. The default value is 50.
Profiling results for the finished threads beyond this limit are merged to
|
onexit=snapshot |
Always capture a performance snapshot on profiled application exit. If this option is not specified, the performance snapshot will be captured on exit if CPU sampling or tracing is running at that moment. |
dir= <directory for snapshots>
|
Specify custom snapshot directory for the particular profiled application |
logdir= <directory> |
By default, the profiler agent log file is Use this option to create logs in different directory.
For example, it can be useful when profiling applications running as a Windows service.
They usually run under special user,
thus the logs are located in that special user's home directory.
For example, it can be
Instead, make the logs created in an arbitrary easily accessible directory,
e.g. |
tmpdir= <directory> |
Specify alternate directory for temporary files created by the profiler agent:
By default, the profiler agent creates the temporary files in the default temporary directory. |
app_name= <name> |
Specify alternate presentable name of the profiled application used in:
If this option is not specified, the application name is automatically chosen based on its executable name.
The default, automatically generated application name can be specified via
For example, to append the host name to the default application name, use
|
snapshot_name_format= <format> |
Specify alternate rule to compose snapshot file names. Available macros:
The default format is Characters not allowed in file names, if specified, will be replaced with '-'. |
sampling_settings_path= <file path> |
Specify a custom location of the CPU sampling settings configuration file.
If this option is not specified,
the settings are read from
|
tracing_settings_path= <file path> |
Specify a custom location of the CPU tracing settings configuration file.
If this option is not specified,
the settings are read from
|
targetclr= <version> |
Choose which of multiple CLR version instances loaded in a single process should be profiled. See MSDN article In-Process Side-by-Side Execution for detail.
Use |
disable_inlining |
Forbids CLR to inline any methods. Specify this option to see all method calls and exact stack traces. Please be aware that the profiled application may run up to 10 times slower. Use this option when invocation counts obtained with CPU tracing and stack trace accuracy for all called methods are more valuable than the time accuracy and lower overhead. |
Control which profiling modes are turned on right from the startNote that you do not have to perform measuring right from the start. Instead, in many cases it's better to start or stop measuring at a later moment - from the UI or by using the Profiler API. |
|
sampling |
Immediately start CPU profiling in the sampling mode. Note that you do not have to profile CPU right from the start; instead, in many cases it's better to start or stop measuring at a later moment - from the UI or by using the Profiler API. |
tracing |
Immediately start CPU profiling in the tracing mode.
Note that you do not have to profile CPU right from the start;
instead, in many cases it's better to start or stop measuring at a later moment -
from the UI or by using the Profiler API.
This option cannot be used in combination with |
alloceach= <N> |
Immediately start object allocation recording, recording each N-th allocation.
This option can be used in combination with
To record only those objects whose size exceeds the threshold set with Note that you do not have to record allocations right from the start; instead, you can start or stop recording later from the profiler UI or using Profiler API. |
allocsizelimit= <size in bytes> |
Immediately start object allocation recording, recording allocation of all objects with size bigger than or equal to the specified value.
This option can be used in combination with Note that you do not have to record allocations right from the start; instead, you can start or stop recording later from the profiler UI or using Profiler API. |
usedmem= <used memory in megabytes> |
Automatically capture a memory snapshot when process used memory reaches the threshold. |
periodicperf= <period in seconds> |
Periodically capture performance snapshots. |
periodicmem= <period in seconds> |
Periodically capture memory snapshots. |
disablestacktelemetry |
Do not collect thread stack and status information shown in Thread view as well as in other telemetry views. This information can be very useful because it allows you to connect to the profiled application on demand and discover how the application behaved in the past. In most cases, there is no significant overhead of collecting this information. However, you may want to stop it to minimize profiling overhead. See also: Profiling overhead: how to reduce or avoid. |
exceptions=off |
Do not start with exception profiling. The exception profiling helps discovering performance issues and logic errors. In most cases, there is no significant overhead of collecting this information. However, you may want to disable it to minimize profiling overhead. See also: Profiling overhead: how to reduce or avoid. |
|
Control probes on startup. Read more... |
triggers= <file path> |
Specify the file with description of the triggers to be applied from startup.
If this option is not specified, the trigger description is read from
By default, that file does not exist, thus no triggers are applied. |
Optimization optionsReduce profiling overhead by disabling some profiling capabilities. These options can be switched on startup only, i.e. corresponding behavior cannot be altered during runtime. See also: Profiling overhead: how to reduce or avoid. |
|
disablealloc |
Disable object allocation notification events in the runtime to totally eliminate corresponding overhead. Object allocation recording will not be available. See also: Profiling overhead: how to reduce or avoid. |
disabletracing |
Disable method enter and leave events in the runtime needed for CPU tracing. CPU tracing will not be available. See also: Profiling overhead: how to reduce or avoid. |
disableall |
Disable several capabilities at once:
|