Products
 
 
 
Fully featured low overhead profiler for Java EE
and Java SE platforms.
Easy to use performance and memory profiler for .NET framework.
Supports ASP.NET, Silverlight, .NET Windows services and more.

previous      content      next
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, 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:

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.

listen=<ip>:<port>

Same as 'port' but this binds agent socket to a particular IP only

onlylocal

Allow only local connections to profiled application

dir=<directory for snapshots>

Specify the directory where snapshots are created. By default, <user home>/Snapshots directory is used.

delay=<time in milliseconds>

Postpone start of telemetry collection. This option is mostly intended to prevent startup issues of some J2EE servers.

By default, light-weight telemetry is collected right from the start of the profiled application.

The telemetry is collected via so called platform MBeans ("managed beans") - the components for monitoring and managing the JVM. Some J2EE servers install their own implementations of standard MBeans. In earliest stages of the server startup the MBeans can not be functional because they depend on other components of the server (such as custom logging) which have not initialized so far. Accessing such MBeans in earliest stages can cause the server startup failure (e.g. with ClassNotFoundException).

The "delay" option ensures that all MBeans are completely initialized before they are first accessed, by postponing the start of collecting the telemetry.

The J2EE integration wizard by default uses "delay=10000" to postpone the telemetry for 10 seconds (since version 7.5.9). Although not all servers (and not all versions of particular server) suffer from the problem with MBeans, it is recommended to always use "delay" profiling a J2EE server to ensure that any J2EE server can successfully start. Furthermore, the telemetry of first few seconds of the server startup is unlikely of any interest for you, because the server's internals are being initialized during that time rather than your own application code.

If the 10 seconds delay is not enough in your particular case, try a bigger value.

onexit=memory

Always capture a memory snapshot on exit. CPU snapshot will be captured automatically if CPU profiling is enabled when the profiled application exits.

onexit=snapshot

Capture recorded data (telemetry, and if recorded CPU and monitors profiling results) on exit. This option is automatically used when the profiled application is started from the IDE.

quiet

Suppress diagnostics messages that the profiler agent prints to the console.


Turn on profiling modes 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

Launch Java application with CPU sampling turned on. 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

Launch Java application with CPU tracing turned on. 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 'disablecounts'.

noj2ee

Do not perform J2EE high level profiling. This option influences only CPU profiling started with 'sampling' or 'tracing'. Read more about CPU profiling modes.

alloc

Launch Java application with object allocation recording started. All objects will be recorded. Note that you do not have to record allocations right from the start; instead, you can start or stop recording later from the Profiler or using Profiler API. This option cannot be used in combination with 'disablealloc'.

alloceach=<N>

Launch Java application with object allocation recording started and record each N-th allocation. This option can be used in combination with 'allocsizelimit'. 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 or using Profiler API.

allocsizelimit=<B>

Launch Java application with object allocation recording started and record allocation of objects with size bigger or equal B bytes. 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 or using Profiler API.

monitors

(Java 5 and newer) Launch Java application with started monitor profiling. Note that you do not have to profile monitor usage right from the start; instead, you can start or stop recording later from the Profiler or using Profiler API.

usedmem=<percent>

Automatically capture a memory snapshot when used heap memory reaches the threshold.


Optimization options

Reduce profiling overhead by disabling some profiling capabilities.
See Profiling overhead: how to reduce or avoid.

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

Do not collect thread stack and status information shown in Thread and Deadlocks 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, and thus you do not need to disable it. However, it makes sense to disable it in production J2EE servers in order to ensure minimum profiling overhead. See Profiling overhead: how to reduce or avoid.

disablealloc

(Java 5 and newer) Do not instrument bytecode with instructions needed for object allocation recording. See Profiling overhead: how to reduce or avoid.

disablecounts

(Java 5 and newer) Do not instrument bytecode with instructions needed for CPU tracing. Only CPU sampling will be available. See Profiling overhead: how to reduce or avoid.

disablej2ee

(Java 5 and newer) Do not instrument bytecode with instructions needed for J2EE profiling. See Profiling overhead: how to reduce or avoid.


Miscellaneous
help

Print brief description of agent parameters.

previous      content      next