See: Description
Package | Description |
---|---|
com.azul.zing.management |
Zing MXBeans provide an interface to answer detailed questions about the behavior of your application and the Zing VM. The MXBeans are designed for both monitoring performance and extracting the low level details to discover the root causes of problems. Thresholds and notifications make long term monitoring easy without requiring the overhead associated with polling. Please see the Javadoc for each of the MXBeans for examples on how to set up notifications.
A program that is able to access the MXBeans and graph the collected metrics, such as JConsole, will aid in your ability to quickly understand the interfaces and their use. The available MXBean operations provide control of both the data collection and the JVM behavior.
When there is a problem or when you simply want to understand the runtime environment, there are common questions that you might want answered. Here is how to approach answering some of those questions using the Zing MXBeans.
The
MemoryMXBean
provides
a method to track the approximate percentage of the total Java heap that
is occupied by long-lived Java objects, the
getPercentJavaHeapOccupiedAfterCollection
method.
Other
MemoryMXBean
methods facilitate tracking of both the total Java heap in use at any
time and separate tracking of the use of the memory pools in the Java heap available
for application object allocation. The JVM process also uses native heap memory and its use
can be tracked by using the
getNonJavaHeapUse
method.
Together, these capabilities provide easy answers to questions about memory use by the process and enable rapid diagnosis of memory leaks and object retention problems.
Use thresholds and notifications to make application Java Heap memory use monitoring easy. The
setPercentJavaHeapOccupiedAfterCollectionThreshold
allows you to tailor the threshold value to be appropriate to your application and its environment.
The
MemoryNotificationInfo
class has the PERCENT_JAVA_HEAP_OCCUPIED_AFTER_COLLECTION_THRESHOLD_EXCEEDED
notification type that you can use in the notification listener to identify
the notifications and create custom actions.
The
GarbageCollectorMXBean
provides an easy application health metric by using its
getPercentageOfTimeCollectorIsRunning
method. Both the New Generation and, more importantly, the Old Generation
collectors can be monitored separately to see whether the application's Java heap
size is appropriate for the work load. If your application is spending more than
thirty percent of the time garbage collecting, consider increasing the amount of
Java heap memory available to the application.
Even better, use the thresholds and notifications to provide you with notifications
when the percentage of time the collector is running exceeds a threshold. You will
want to look at
setPercentageOfTimeCollectorIsRunningThreshold
and the corresponding notification type in
GarbageCollectorNotificationInfo
named PERCENTAGE_OF_TIME_COLLECTOR_IS_RUNNING_THRESHOLD_EXCEEDED
.
The answer is simple to obtain; the
MemoryMXBean
method named
isJavaHeapUsingMoreMemoryThanInitiallyReserved
answers the question with one call. The
MemoryMXBean
also provides an event-based notification that is easy to set up and
check for the JAVA_HEAP_USING_MORE_MEMORY_THAN_INITIALLY_RESERVED
notification. All you need to
do is to add a notification listener. Please see the example in the
MemoryMXBean
Javadoc.
The Java Heap can also be monitored using a set of calls to obtain the peak memory usage and the memory usage immediately following a garbage collection. You have the flexibility to reset the historical peak value stored by the JVM, so you can collect the peak usage over any interval of time. Here are the methods to use:
getPeakUsage
- Peak MemoryUsage since JVM startup or since the last reset of the peak.
resetPeakUsage
- Resets the peak memory usage to the value at the end of the last previously completed garbage collection.
getTimeOfLastResetPeakUsageSec
- Returns the time in seconds from the start of the program until the last reset of the peak memory usage.
Similar sets of methods enable collection of peak and cumulative metrics for many JVM performance and behavior characteristics. Together with the control of the time interval for metric collection provided by the reset operations, the accumulators and peaks become a powerful tool for monitoring and diagnosing problems.
The Zing MXBeans use
MemoryUsage
objects to characterize memory pool sizes using the following terminology:
MemoryPoolSizeType
- Describes the size "type" of the memory pool, whether it is a
FIXED
size or can expand and/or contract in size and is therefore
ELASTIC
in size.
FIXED (used never exceeds initialReserved) initialReserved X +-----------------------------------------------------------------+ |UUUUUUUUUUUUUUUUUU | +-----------------------------------------------------------------+ used size ELASTIC (large initialReserved and used < initialReserved) initialReserved X +-------------------------------------------+ |UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU| +-------------------------------------------+ used size ELASTIC memory pools frequently have sibling and parent memory pools that are elastic. ELASTIC (small initialReserved and used > initialReserved) initialReserved X +----------------------------------------------------+ |UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU| +----------------------------------------------------+ used size
Too much time spent in stop-the-world pauses can seriously disrupt the performance of Java applications.
Measuring and understanding the frequency and duration of these pauses is important to the understanding of
the impact of the pauses on application performance. The
GarbageCollectorMXBean
provides detailed information about the pauses required to perform garbage collections and a method
you can use to track when the longest pauses occur:
getCollectorCumulativePauseTimeSec
- Cumulative pause time required by this collector to do its collections.
As with other accumulators, this metric has an associated
resetCollectorCumulativeCounters
operation to control the time period over which the pause data is collected.
getCollectorMaxPauseDetails
- Returns an array of
PauseDetails
objects for each of the pauses required by the collector.
And, of course, the saved, historical maximum PauseDetails for each of the required pauses
can be reset using the
resetCollectorMaxPauseDetails
operation.
When you want to monitor only those pauses longer than a specific duration, use thresholds
and notifications,
setGarbageCollectionPauseDurationThreshold
and the corresponding notification type in
GarbageCollectorNotificationInfo
named GARBAGE_COLLECTION_PAUSE_DURATION_THRESHOLD_EXCEEDED
.
Each
PauseDetails
has three fields to facilitate the tracking of the time when the pause occurred, the duration
of the pause and the reason for the pause.
To make tracking and problem reporting easier, the Zing MXBeans provide a convenient method to convert the timestamps that are used in the MXBeans, the elapsed time since the JVM start in seconds, to a formatted Date-Time string:
convertElapsedTimeSinceJVMStartSecToDateTimeString
- Returns a Date-Time String representing the date and time of the elapsed time since the JVM start in seconds.
Zing MXBeans provide the interfaces that enable you to get the answers you need to understand your application's performance. Flexibility in the management of the values stored as peak values and those available in accumulators makes it easy to tailor the collection of the data for efficiency and effectiveness. Thresholds and notifications help to automate the monitoring of applications, reducing the amount of work you need to do and returning context when a notification occurs.
Submit a bug or feature request
Copyright © 2015-2017, Azul Systems, Inc. All rights reserved.
Azul Systems and Zing are registered trademarks of Azul Systems, Inc.