Skip to content

Application Profiling with YourKit

jhou-pro edited this page Nov 7, 2014 · 20 revisions

Application Profiling with YourKit

  1. Application profiling purposes
  2. YourKit setup
  3. Basic profiling
  4. Detailed profiling

Application profiling purposes

It is very important to see the big picture of how your application works, how much resources it consumes and what is the health of the application. This is especially critical for production systems, in which the errors or stoppages during the application lifecycle are strongly undesirable.

But there is a good reason to see the big picture during the application development stage to take a better control of, for example, leaking memory resources or CPU usage. This is not a subject of premature optimisation but the subject to identify hardly visible programming insufficiencies and weaknesses. There is also a good time to monitor application health before releasing new major version to identify which parts of the application can be optimised.

This is application profiling all about. And YourKit is one of the most comprehensive and stable profilers at Java profiling market.

YourKit setup

To profile the remote / local application by YourKit the best way is to include YourKit agent in the application during its startup and then connect to the instrumented application using YourKit GUI.

Also there are capabilities to instrument the application during its normal lifecycle, but it has some limitations, especially when profiling is performed remotely (see Attaching profiler agent to a running JVM).

  1. To add profiler agent to the application:

  2. install YourKit to the application host;

  3. include JVM parameter -agentpath:YOURKIT_HOME_DIR/bin/linux-x86-64/libyjpagent.so or -agentpath:YOURKIT_HOME_DIR\bin\win32\yjpagent.dll to app startup script (based on the app host's OS and CPU architecture).

  4. To start application profiling GUI:

  5. install YourKit to the profiling host;

  6. start YourKit GUI and provide a lisence key (required);

  7. connect to the profiled application (either choose from the list of local applications of select Connect to remote application... and enter host).

Basic profiling

The basic profiling is intended to identify major application problems such as high CPU / memory utilisation, garbage collection problems, sockets, database connections and queries overflows etc. In most cases basic profiling is sufficient to investigate that problems and make appropriate decisions about the application logic, which cause that problems.

CPU usage

Select some CPU intensive range to identify which java methods cause excessive utilisation.

Memory usage

Memory tab shows a basic view of utilised memory with a separation to Old Generation and Eden Space, which are covered by All Allocated Pools. The Old Generation shows the objects that have survived after the garbage collection. Eden Space shows the objects that have been created recently and should be collected soon. All Allocated Pools show how much additional memory space JVM uses to be comfortable with garbage collection.

Garbage collection

Intensive garbage collection or its high frequency shows that there is no enough memory to efficiently process the data, which is created during application lifecycle.

Performance charts

Performance charts include sockets, database connections / statements / preparedStatements, input / output streams, servlet requests and others. They are very useful when some of that resources are leaking or badly responsive.

Detailed profiling

To capture more details of CPU or memory usage there are comprehensive tools: CPU and memory snapshots. They can be analysed from different perspectives and give us more accurate calculations.

There are capabilities to calculate some CPU / memory details during application normal lifecycle, but it has some limitations, especially when profiling is performed remotely (see Start CPU profiling and Start Object Allocation Recording buttons).

The snapshots can be huge -- their sizes are approximate to the sizes of the application memory, that is why we should be comfortable with the bandwidth (to transfer the snapshot from the remote host) and the disk / memory space (at the remote / local host).

Clone this wiki locally