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.

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

Allow only local connections to profiled application

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

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.

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

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.

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

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.

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'.

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

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'.

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.

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.

(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.

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

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.

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

(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.

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

Print a short description of agent parameters.