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.

Attaching profiler agent to a running JVM

To profile a Java application, the profiler agent should be loaded into the JVM.

There are two ways to do it:

  • Start the profiled application with the profiler agent, using IDE integration, local and remote Java EE server integration wizard, or manually specifying appropriate JVM option.
  • Attach the profiler agent to a running JVM instance on demand.

The second approach (attach mode) simplifies profiling, making it even more "on-demand profiling" than ever. Avoid a special step to enable profiling: any running Java application can be profiled.

How to attach to a local application

In Welcome screen, click corresponding element in the list.

The list of applications to attach (both in UI and when using remote attach wizard) contains applications detected via standard JVM enumeration mechanism, as well as applications not detected via standard JVM enumeration mechanism, such as Tomcat running as Windows service, or processes java.exe and javaw.exe running under different user (in particular, other Java EE servers started as Windows service).

Anyway, it is possible that a Java application which was not started with standard Java launcher (java, java.exe, javaw.exe), or was started under a different user, will not be automatically detected and thus will not be shown in the list of locally running applications.

To profile such application, use "Attach by PID" (you can learn the PID via Task Manager in Windows or ps command on non-Windows). After successful attach, the application will appear in the list.

How to attach to a remote application

Run attach wizard on the remote machine, then use "Connect to remote application..." from Welcome screen.

The attach mode limitations

Unfortunately, the attach mode is not an ultimate solution. The problem is that existing JVMs provide only limited set of profiling capabilities for the attached agents. To get all profiling capabilities, you still have to start the profiled application with the profiler agent instead.

  • The attach mode is only supported for Sun Java (HotSpot) and JRockit.

    Existing IBM VMs do not provide necessary capabilities to let YourKit Java Profiler function in the attach mode. To profile on IBM Java, please start application with the profiler agent. If necessary capabilities are added in future versions of IBM Java, the profiler will support attach mode for IBM Java too.

  • Attach may fail due to insufficient access rights. For example, it may not be possible to attach to a Java EE server running as a Windows service. If attempt to attach fails, start the application with the profiler agent instead.

  • Client JVM can crash in attach mode due to a JVM bug

    Due to a JVM bug 6776659 HotSpot client JVM can crash in attach mode.

    There is no crash for the server JVM: JVM option -server solves the problem.

  • A long pause is possible on first attempt to start CPU tracing or object allocation recording, because classes loaded before the profiler agent has attached need to be instrumented. Depending on application, it can take from several seconds to several tens of seconds, or even a few minutes in worst cases.

    The good news is that there will be no pause on subsequent starts of CPU tracing or object allocation recording for the same running JVM instance.

  • No profiling results for some methods:

    • JVM may not be able to apply bytecode instrumentation to methods of the objects that have been created before the agent attached. Instead, the old, non-instrumented version of the bytecode will keep running for them. This is a limitation of the JVM.
    • Another JVM limitation is that native methods of classes that have loaded before the profiler agent attached cannot be instrumented at all. (There is no problem with classes loaded after the profiler has attached.)

    This means that their calls will be missing in:

    • CPU tracing results (no problem for CPU sampling as it does not depend on bytecode instrumentation)
    • results of probes depending on instrumentation of those methods, in particular, in the "Events" and "Performance Charts" views
  • Exception telemetry is not available