Although the profiler started this way will have minor UI defects such as non-native main menu style and an incorrect application icon in the dock, in general it will work just fine.

Note: since build 14112 the profiler falls back to this approach automatically, i.e. tries to restart itself via yjp.sh after a crash.

Linux, Solaris, AIX, HP-UX, FreeBSD

Unpack the installation bundle and run <Profiler Installation Directory>/bin/yjp.sh

The profiler UI requires Java 8 to run. The download bundle contains JRE for Linux x64 and should run out of the box on that platform. On other platforms, please ensure that the appropriate Java version is installed.

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 the profiled application.
`delay`=<milliseconds>	Postpone start of telemetry collection. This option is mostly intended to prevent startup issues of some Java EE servers. By default, lightweight 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 Java EE 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 Java EE integration wizard by default uses `delay=10000` to postpone the telemetry for 10 seconds. Although not all servers (and not all versions of particular server) suffer from the problem with MBeans, it is recommended to always use the delay when profiling a Java EE server to ensure that any Java EE 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.
`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. Read more...
`deadthreadlimit`=<threads>	Specify the number of recently finished threads for which CPU sampling, tracing and monitor 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=memory`	Always capture a memory snapshot on profiled application exit. If this option is not specified, the memory snapshot will be captured on exit if object allocation recording is running at that moment.
`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 or monitor profiling is running at that moment. This option is automatically added when the profiled application is started from the IDE.
`dir`=<directory for snapshots>	Specify custom snapshot directory for the particular profiled application
`logdir`=<directory>	By default, the profiler agent log file is `<user home>/.yjp/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`
`united_log`	Store logs from several runs of the same application as a series of log files named <session name>`.`<running number>`.log` instead of creating an individual log file `<session name>-<PID>.log` for each profiled process. This mode may simplify log maintenance and cleanup when profiling applications such as servers. Session name is the presentable name of the application; see the startup option `sessionname`=<name> for detail. Running number starts with 1. If the first log file <session name>`.1.log` exceeds the size limit, a new log file <session name>`.2.log` will be created and used, then <session name>`.3.log` etc. The size limit is 1 MB by default, and can be changed with the startup option `log_file_size_limit=`<bytes> Note: the oldest log files are not automatically removed. If you need to clean them up, do it manually or write a script.
`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 main jar file name, or its main class name, or the custom executable name, or on the run configuration name when profiling from within IDE.
`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>/.yjp/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>/.yjp/tracing.txt`, where user home corresponds to the account under which a profiled application is launched.
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`.
`call_counting`	Immediately start CPU profiling in the call counting 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`, but is mutually exclusive with `alloc_object_counting`. This option cannot be used in combination with `disablealloc`. (Since 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 specified value. This option can be used in combination with `alloceach`, but is mutually exclusive with `alloc_object_counting`. 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.
`allocsampled`	Use sampled object allocation recording. This option influences only object allocation recording started `alloceach` and `allocsizelimit`.
`alloc_object_counting`	Immediately start object allocation recording in the object counting mode. This option is mutually exclusive with `alloceach` and `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 UI or using Profiler API.
`monitors`	Immediately start 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 UI or using Profiler API.
`usedmem`=<percent>	Automatically capture a memory snapshot when used heap memory reaches the threshold. Note: this option just adds corresponding trigger on startup. Use triggers directly for a more sophisticated functionality.
`usedmemhprof`=<percent>	Automatically capture a HPROF snapshot when used heap memory reaches the threshold. Note: this option just adds corresponding trigger on startup. Use triggers directly for a more sophisticated functionality.
`periodicperf`=<period in seconds>	Periodically capture performance snapshots. Note: this option just adds corresponding trigger on startup. Use triggers directly for a more sophisticated functionality.
`periodicmem`=<period in seconds>	Periodically capture memory snapshots in the profiler's format (*.snapshot). Note: this option just adds corresponding trigger on startup. Use triggers directly for a more sophisticated functionality.
`periodichprof`=<period in seconds>	Periodically capture HPROF snapshots. Note: this option just adds corresponding trigger on startup. Use triggers directly for a more sophisticated functionality.
`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, it makes sense to disable it in production Java EE servers in order to ensure minimum profiling overhead. See also: Profiling overhead: how to reduce or avoid.
`exceptions=on`	Enable exception events in the JVM and immediately start recording the exception telemetry. This is the default mode on Sun/Oracle HotSpot, OpenJDK, JRockit (i.e. non-IBM JVMs). See also: Profiling overhead: how to reduce or avoid.
`exceptions=off`	Enable exception events in the JVM but do not immediately start recording the exception telemetry that can instead be recorded later in runtime. See also: Profiling overhead: how to reduce or avoid.
`exceptions=disable`	Fully disable exception events in the JVM to totally eliminate corresponding overhead. The exception telemetry will not be available. This is the default mode on IBM JVMs because the overhead is significant. See also: Profiling overhead: how to reduce or avoid.
`disableoomedumper`	Disable on OutOfMemoryError snapshots. Note that enabling on OutOfMemoryError snapshots adds absolutely no overhead. If OutOfMemoryError happens, memory snapshot is written to disk for further analysis. You may want to disable the snapshots in some very special situations, e.g. if you profile an application with a huge heap, for which capturing the snapshot may take significant resources (time and/or disk space), but do not plan to perform its memory analysis.
`probe_on`=<pattern> `probe_off`=<pattern> `probe_auto`=<pattern> `probe_disable`=<pattern>	Specify which probes should be registered on startup. Read more...
`probeclasspath`=<classpath>	Specify where to find probe class(es) which are registered by class name. Read more...
`probebootclasspath`=<classpath>	Specify where to find probe class(es) which are registered by class name. 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 `<user home>/.yjp/triggers.txt`, where user home corresponds to the account under which a profiled application is launched. By default, that file does not exist, thus no triggers are applied.
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=disable`, `disablestacktelemetry`, `probe_disable=*`
Miscellaneous
`help`	Print brief description of startup options.

Platform		VM option
Windows	32-bit Java	`-agentpath:<profiler directory>\bin\win32\yjpagent.dll`
Windows	64-bit Java	`-agentpath:<profiler directory>\bin\win64\yjpagent.dll`
Mac OS X		`-agentpath:<profiler directory>/bin/mac/libyjpagent.jnilib`
Linux	x86, 32-bit Java	`-agentpath:<profiler directory>/bin/linux-x86-32/libyjpagent.so`
	x86, 64-bit Java	`-agentpath:<profiler directory>/bin/linux-x86-64/libyjpagent.so`
	ARMv7, hard-float	`-agentpath:<profiler directory>/bin/linux-armv7-hf/libyjpagent.so`
	ARMv5, soft-float	`-agentpath:<profiler directory>/bin/linux-armv5-sf/libyjpagent.so` You may also need to add `libstdc++.so.6` to `LD_LIBRARY_PATH` to satisfy dependencies
	ARM AArch64	`-agentpath:<profiler directory>/bin/linux-aarch64/libyjpagent.so`
	ppc, 32-bit Java	`-agentpath:<profiler directory>/bin/linux-ppc-32/libyjpagent.so`
	ppc64, 64-bit Java, big-endian	`-agentpath:<profiler directory>/bin/linux-ppc-64/libyjpagent.so`
	ppc64le, 64-bit Java, little-endian	`-agentpath:<profiler directory>/bin/linux-ppc-64/libyjpagent.so`
Solaris	SPARC, 32-bit Java	`-agentpath:<profiler directory>/bin/solaris-sparc-32/libyjpagent.so`
	SPARC, 64-bit Java	`-agentpath:<profiler directory>/bin/solaris-sparc-64/libyjpagent.so`
	x86, 32-bit Java	`-agentpath:<profiler directory>/bin/solaris-x86-32/libyjpagent.so`
	x86, 64-bit Java	`-agentpath:<profiler directory>/bin/solaris-x86-64/libyjpagent.so`
HP-UX	IA64, 32-bit Java	`-agentpath:<profiler directory>/bin/hpux-ia64-32/libyjpagent.so`
HP-UX	IA64, 64-bit Java	`-agentpath:<profiler directory>/bin/hpux-ia64-64/libyjpagent.so`
AIX	ppc, 32-bit Java	`-agentpath:<profiler directory>/bin/aix-ppc-32/libyjpagent.so`
AIX	ppc64, 64-bit Java	`-agentpath:<profiler directory>/bin/aix-ppc-64/libyjpagent.so`
FreeBSD	x86, 32-bit Java	`-agentpath:<profiler directory>/bin/freebsd-x86-32/libyjpagent.so`
FreeBSD	x86, 64-bit Java	`-agentpath:<profiler directory>/bin/freebsd-x86-64/libyjpagent.so`

Comparison criteria	CPU usage estimation	"Real" CPU sampling	Comments
Results availability	Always, as long as stack telemetry is enabled	Should be explicitly started	CPU usage estimation is ideal for analysis of anomalies such as CPU spikes, especially those which has already happened, so you do not need to turn CPU sampling or tracing on and try reproduce the spike.
Accuracy	Lower	Higher	CPU usage estimation is based on thread telemetry, whose frequency is normally as low as 1 sample per second (can be changed using the startup option telemetryperiod). CPU usage estimation can adequately measure events not shorter than the thread telemetry period. So, it suits for measuring events or method calls that last at least several seconds. If the measured event or method call is long enough, the estimation will do its job - locate problematic code responsible for the CPU spike. For measuring shorter events or methods, use normal CPU profiling, or decrease the telemetry period using the startup option telemetryperiod.
Granularity	Results are available for each particular event, as well as for entire time range	Results are aggregated for entire period of CPU profiling	CPU usage estimation enables analysis of particular events or time ranges within single snapshot. CPU profiling results are aggregated since CPU profiling has been started. It is not possible to "extract" CPU profiling results for a smaller time range within one snapshot. However, you can choose which method calls to analyze.

Probes	Default mode
JSP/Servlets, databases, files, sockets	Auto
Class loading, threads, processes, AWT events	On
JUnit and TestNG tests	On (*)
user-defined probes	n/a (On or Auto explicitly specified)

Part	Description	Examples
`class_name`	Full qualified class name, dot-separated. Inner class part(s) are separated with "$" sign.	Particular class: `com.foo.Bar` Class with name ending with 'Helper': `Helper` Any class in a package: `java.io.` Any class: `*`
`class_annotation` (optional)	Specify that matching classes must have particular annotation. If not specified, class with any annotations or with no annotations at all will match.	All `toString` methods in classes in package `com.bar` annotated with `@Foo`: `@Foo com.bar.* : toString()`
`method_name`	Method name. To specify a constructor, use `<init>`.	Method with particular name: `toString` Any getter: `get` Any method, including constructors: ``
`method_annotation` (optional)	Specify that matching methods must have particular annotation. If not specified, methods with any annotations or with no annotations at all will match.	All JUnit tests: `:@org.junit.Test ()`
`parameter_types`	Comma-separated list of parameter types. Space characters between type names and commas are allowed (but not required). Class names should be full qualified, dot-separated, except for `java.lang.Object`, `java.lang.Object[]`, `java.lang.String`, `java.lang.String[]` for which a short form is allowed: `Object`, `Object[]`, `String`, `String[]`. Primitive types should be named as in Java source code: `int`, `char` etc. Arrays are specified as `<type>[]`. Use empty string to specify a method with no parameters.	No parameters: empty Any number of parameters, including zero: `` 3 parameters of particular types: `String, int, int` First parameter is an array of class com.Foo: `com.Foo[], `

Type of callback parameter annotated with @Param	Actual instrumented method parameter type	Resulting value of the callback parameter
`java.lang.Object`	any reference type	the value as is
`java.lang.Object`	any primitive type	a boxed value
some reference type `T1` other than `java.lang.Object`	same reference type `T1`	the value as is
some reference type `T1` other than `java.lang.Object`	any reference or primitive type `T2 != T1`	null
some primitive type `T1`	same primitive type `T1`	the value as is
some primitive type `T1`	any reference or primitive type `T2 != T1`	0

	If `@This` is used in onEnter(), or onUncaughtException(), or onUncaughtExceptionExt(), or if `@This` declared as non-`java.lang.Object` is used in onReturn()	Otherwise
`onEnter()` injection point	onEnter() will be called right after the call to `super(...)` or `this(...)`	onEnter() will be injected at the very start of the constructor, i.e. before the call to `super(...)` or `this(...)`
`onUncaughtException()` or `onUncaughtExceptionExt()` monitored scope	The scope of monitored exceptions will start right after the call to `super(...)` or `this(...)`	The scope of monitored exceptions will be the whole method, i.e. will include the call to `super(...)` or `this(...)`

Type of callback parameter annotated with @ReturnValue	Actual instrumented method return value type	Resulting value of the callback parameter
`java.lang.Object`	any reference type	the value as is
	any primitive type	a boxed value
	void	null
some reference type `T1` other than `java.lang.Object`	same reference type `T1`	the value as is
	any reference or primitive type `T2 != T1`	null
	void	null
some primitive type `T1`	same primitive type `T1`	the value as is
	any reference or primitive type `T2 != T1`	0
	void	0

Profiler version	URL
YourKit Java Profiler 2017.02	`https://www.yourkit.com/download/yjp2017_02_for_eclipse/`
YourKit Java Profiler 2016.02	`https://www.yourkit.com/download/yjp2016_for_eclipse/`
YourKit Java Profiler 2015	`https://www.yourkit.com/download/yjp2015_for_eclipse/`
YourKit Java Profiler 2014	`https://www.yourkit.com/download/yjp2014_for_eclipse/`

Figure 1:	Figure 2:

1 Running the profiler

Windows

Mac OS X

Troubleshooting: what to do if the profiler crashes on startup

Linux, Solaris, AIX, HP-UX, FreeBSD

2 Running applications with the profiler

Local and remote profiling

The profiler agent

Approach 1: Start JVM with the profiler agent

Approach 2: Attach the profiler to a running JVM instance started without the agent

Supported JVMs

Supported platforms

2.1 Local profiling

1. Ensure the local application is running with the profiler agent

Java SE application

Java EE application (EE server)

Profiling Java Web Start/JNLP

Applet

2. Connect to the local application

2.2 Remote profiling

1. Ensure the remote application is running with the profiler agent

2. Connect to the remote application

2.2.1 Console version of Java EE server integration wizard

Running the wizard

On Windows

On other platforms

2.2.2 Remote attach wizard

On Windows

On other platforms

2.3 Startup options

What are the startup options?

When should I specify the startup options?

How can I specify the startup options?

Description of the startup options

Main options

Control which profiling modes are turned on right from the start

Optimization options

Miscellaneous

2.4 Attaching profiler agent to a running JVM

How to attach to a local application

How to attach to a remote application

The attach mode limitations

2.5 Profiling overhead: how to reduce or avoid

Overhead of running an application with the profiler

Overhead when measuring is performed

Snapshot capture

Thread stack and status telemetry

Exception telemetry

2.6 Enabling profiling manually

Step 1: Add VM option '-agentpath'

Step 2: (Optional) Specify startup options

Examples

2.7 About JVMTI (advanced topic)

What a Java profiling API is

3 Connect to profiled application

Connect to locally running profiled application

Connect to remote application

Examples

Remote profiling troubleshooting

Web interface: check agent status in web browser

In connected mode

4 Solving performance problems

What performance problems may arise?

Why memory-related issues can cause performance problems?

4.1 Performance bottlenecks

How to find a performance bottleneck using CPU profiling?

4.2 Optimizing memory usage

How to find out why application eats that much memory?

4.3 Memory leaks

What is a memory leak?

How to find memory leaks?

1. Detect memory leak, i.e. understand what objects do exist while they should not.

2. Once you have found leaked object(s), it's time to understand why they are retained in memory

4.3.1 GC roots

4.4 Excessive garbage allocation

How to find excessive garbage allocation?

4.5 Out of memory error (OutOfMemoryError and -XX:+HeapDumpOnOutOfMemoryError)

5 CPU profiling

5.1 CPU usage telemetry

5.2 Start CPU profiling. Sampling, tracing, call counting.