Sampling based diagnostics

When to use sampling

AppMon automatically captures performance relevant method invocations (shown in the CPU Sampling dashlet) and does not define explicit sensors. Therefore, you would use CPU sampling to:

  • Identify an entry point: Find your custom entry points to define Custom Entry Point Sensors.
  • Analyze background threads: If AppMon does not capture threads as PurePaths, analyze them with CPU sampling.

Sampling FYIs

  • Sampling investigates the current stack of all running Java or .NET application threads to determine if a method is long running or called very often.
  • Sampling doesn't see calls across thread or application boundaries as do PurePaths dashlet.
  • CPU times are measured on a per thread basis, not per method. To visualize it per method, CPU time is assigned to methods based on the number of times a method is seen as the executing one.

Limitations

CPU sampling for Java is available for Java versions 1.5+ and .NET versions 1.1+.

Wording

leaf method A method that has been seen at least once at the top of a stack trace. When the method sees the stack trace, it is executing.
active thread A method is counted active if the thread is currently in a runnable state.
inactive thread A method is counted inactive if the thread it is executed in is blocked or waiting.

Sampling sessions

Sampling sessions receive an incomplete state when sampling stops unexpectedly. This occurs when the collector at the agent connection stops, or when the agent itself stops. You can open incomplete sampling sessions like you open correctly finished sessions.

Sampling session interpretation

Stacktraces grouping

Hotspot view

In the Hotspot tree, all methods that are seen executing are root nodes. The callers of the methods are the tree children.

Group by root methods

In this view, all grouped stack traces ignore the thread in which they were executed. This is useful if you don't care about the thread in which your method is executed. This is true for code that is executed by thread pools (like worker threads of web-applications).

Group by thread

All stack traces are grouped by the thread in which they were executed.

Filtering capabilities

Press Ctrl-F to filter the tree. The following predefined filtering capabilities are at the top-right:

  • The Package filter hides methods that are called from the same package. This shows only methods where the parent node in the tree is a method of another package.
  • The Hide Delegates filter hides methods that are always seen together with the calling method.
  • The Only Active filter ignores threads that are only seen inactive. This is enabled by default. If you are looking for synchronization or similar problems, disable this filter.

The nodes that match your filter text always display, even if the Hide Same Package filter or Hide Delegates filter is enabled. When you switch to search mode, the behavior is different. Nodes that match your search do not display if they are hidden by these filters.

Accuracy

Methods may be shown as hotspots, however these methods are cheap. The JVM doesn't hold the threads exactly when the stack traces are requested, but only on so-called safe points. Safe points have their origins in garbage collection. The Hotspot JVM sets a safe point when it exits a method and a stack trace displays when a method returns.

Errors

No methods consuming CPU time have been found

Reasons:

  • No methods have been seen active while the thread in which they were running consumed CPU time.
  • The sampling session was created with an AppMon version lower than 3.5, where this data wasn't written.

No waiting methods have been found

Reasons:

  • No methods have been seen in inactive state. This applies to .NET because sampling only regards managed code.
  • The sampling session was created with an AppMon version lower than 3.5, where this data wasn't written.

CPU usage in overview differs from an operating system process monitor output

This can happen because AppMon sampling does not apply to native threads.