Fully featured low overhead profiler for Java EE and Java SE platforms.
Monitoring and profiling solution for Gradle, Maven, Ant, JUnit and TestNG.
Easy to use performance and memory profiler for .NET framework.

Startup options

What are the 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.

The options are comma-separated if you specify more than one option.

Description of the startup options

Main options

These options can be switched on startup only, i.e. corresponding behavior cannot be altered during runtime.

port=<value>

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.

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 telemetrylimit option you can customize the time period within which the telemetry data is being stored.

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 CPU sampling or tracing profiling results are kept (the default value is 50). Profiling results for the finished threads beyond this limit are merged to <Oldest finished threads> pseudo-thread node. The intention is to limit collected data size when profiling applications constantly creating new short living threads.

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.

logdir=<directory>

By default, the profiler agent log file is <user home>\.ynp\log\<session name>-<PID>.log

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 C:\WINDOWS\system32\config\systemprofile. It can be difficult to find that directory and to open it in explorer.

Instead, make the logs created in an arbitrary easily accessible directory, e.g. logdir=c:\log

sessionname=<name>

Specify alternate presentable name of the profiled application used in:

  • the profiler UI;
  • snapshot names;
  • log file name.

If this option is not specified, the session name is automatically chosen for particular application basing on its executable name.

snapshot_name_format=<format>

Specify alternate rule to compose snapshot file names.

Available macros:

  • {sessionname} - session name
  • {date} - snapshot capture date in format 'yyyy-MM-dd'
  • {datetime} - snapshot capture date and time in format 'yyyy-MM-dd-HH-mm'
  • {pid} - profiled process ID

The default format is {sessionname}-{date}.

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 <user home>/.ynp/sampling.txt, where user home corresponds to the account under which a profiled application is launched.

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 <user home>/.ynp/tracing.txt, where user home corresponds to the account under which a profiled application is launched.

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 targetclr=v4 to profile CLR 4 instance or targetclr=v2 to profile CLR 2 instance.

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 start

Note 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 CPU 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 CPU 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 disabletracing.

alloceach=<N>

Immediately start object allocation recording, recording each N-th allocation.

This option can be used in combination with allocsizelimit. This option cannot be used in combination with disablealloc.

(Since version 2016.02) To record only those objects whose size exceeds the threshold set with allocsizelimit please specify alloceach=0.

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 alloceach. This option cannot be used in combination with disablealloc.

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 disable it to minimize profiling overhead.

See also: Profiling overhead: how to reduce or avoid.

exceptions=off

Do not collect exception telemetry. The exception telemetry 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.

probe_on=<pattern>

probe_off=<pattern>

probe_auto=<pattern>

probe_disable=<pattern>

Control probes on startup. Read more...

Optimization options

Reduce 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

Do not instrument bytecode with instructions needed for object allocation recording.

See also: Profiling overhead: how to reduce or avoid.

disabletracing

Do not instrument bytecode with instructions needed for CPU tracing. Only CPU sampling will be available.

See also: Profiling overhead: how to reduce or avoid.

disableall

Disable several capabilities at once: disablealloc, disabletracing, exceptions=off, disablestacktelemetry, probe_disable=*