JConsole's manual for monitoring a running JVM

JConsole

JConsole is a JMX-based GUI tool for connecting to a running JVM, but this JVM needs to be started in managed mode. If you want to start an application in a manageable form, you can set it at startup com.sun.management.jmxremote. For example, to start a J2SE application Java2Demo that can be monitored locally, enter the following command:

   JDK_HOME /bin/java -Dcom.sun.management.jmxremote -jar JDK_HOME /demo/jfc/Java2D/Java2Demo.jar  JDK_HOME需要 is a directory containing JDK5.0.

To start JConsole, run JDK_HOME /bin/jconsole and a dialog for connecting will open.   
 The Local tab of the dialog lists all locally running JVMs and also contains information such as the ID of the process.

Figure 2: Local Tab.

JConsole can connect to a running JVM in three ways:

• Local: Use JConsole to connect to a JVM running on the local system, and the executor and the user running JConsole need to be the same user. JConsole uses the file system's authorization to connect to the platform's MBean server through the RMI connector. This monitoring capability from a local connection is only available in Sun's JDK
• Remote: Use the following URL to connect to a JMX broker through the RMI connector:

             service:jmx:rmi:///jndi/rmi:// hostName : portNum /jmxrmi

        hostName fill in the host name, portNum is the port specified when the JMX agent is started. In order to establish a connection, JConsole needs to be set in the environment variable mx.remote.credentials来指定用户名和密码从而进行授权。


• Advanced: Use a special URL to connect to the JMX proxy. In general, use your own custom connector instead of the connector provided by RMI to connect to the JMX agent, or an application that implements JMX and JMX Rmote using JDK1.4.

When JConsole successfully establishes a connection, it obtains information from the JMX agent on the connection and presents the information in the following tabs.

• Summary tab. Information on monitoring the JVM and some monitoring variables.
• Memory tab. Memory usage information
• Threads tab. Thread usage information
• Classes tab. Class call information
• VM tab. JVM information
• MBeans tab. Information on all MBeans

The MBeans tab shows all MBeans registered to the JVM in a generic form. The MBeans tab allows you to get all platform information, including those not available from other tabs. Note that some information on other tabs is also displayed here in MBeans. Additionally, you can manage your own application's MBeans using the MBeans tag

 

Monitor and manage MBeans with the MBeans Tab

The platform or application MBeans registered to the JMX agent can be obtained through the MBeans tag. For example, memory MBeans are defined as follows

public interface MemoryMXBean {
     public MemoryUsage getHeapMemoryUsage();
     public MemoryUsage getNonHeapMemoryUsage();
     public int         getObjectPendingFinalizationCount();
     public boolean     isVerbose();
     public void        setVerbose(boolean value);
     public void        gc();
 }

Memory MBeans include four attributes:

• HeapMemoryUsage.read -only property describing the current heap memory usage
• NonHeapMemoryUsage. A read-only property describing the current non-heap memory usage
• ObjectPendingFinalizationCount. is used to describe how many objects are pending for recycling.
• Verbose. is used to dynamically set whether GC is followed by detailed stack information, as a boolean variable

Memory MBeans support an operation, GC, which can send real-time garbage collection requests.

Figure 3: MBeans Tab.

The tree structure on the left shows a list of all MBeans by name. The name of an MBean object consists of a field name and a string of key attributes. For example, the platform MBeans of the JVM are a group under the "java.lang" domain, while the log MBeans are under the " java.util.logging" domain. The names of MBean objects are defined in the javax.management.ObjectName specification.

When you select an MBean in the tree, some information such as properties, methods, or notifications will be displayed on the right. If the property is writable (the property is marked blue), you can set it. You can operate the operations listed in the Operations tab . You can also see notifications sent by MBeans: by default, if you don't subscribe to notifications, JConsole will not receive notifications about MBeans. You can click "Subscribethe "(Subscribe) button to stack notifications to define, and use the " Unsubscribe" button to unsubscribe

Figure 4: MBeans Notification.

 

monitor memory

The memory tab page obtains statistics on memory consumption, memory pool, and garbage collection by reading the memory system, memory pool, and garbage collected MBeans.
picture:

The graph above shows memory usage over time. There are heap, non-heap and special memory pool statistics. Whether memory pool information can be obtained depends on the Java virtual machine used. The following list shows the memory pools of the HotSpot virtual machine.

Eden Space (heap): Memory is initially allocated from this thread pool to most objects.
Survivor Space (heap): Used to save objects that have not been recycled after garbage collection in the eden space memory pool.
Tenured Generation (heap): Used to keep objects that have existed in the survivor space memory pool for a period of time.
Permanent Generation (non-heap): Save the virtual machine's own static (refective) data, such as class (class) and method (method) objects. The Java virtual machine shares these class data. This area is divided into read-only and write-only,
Code Cache (non-heap): The HotSpot Java Virtual Machine includes a memory for compiling and saving native code, called the "code cache" )

The details area gives some information about the current thread:
Used : Used: The current memory usage. The memory used includes the memory occupied by all objects (which can and cannot be acquired).

Committed : allocated amount: the amount of memory that the Java virtual machine is guaranteed to be able to obtain. The amount of allocated memory (committedmemory) may change over time. The Java virtual machine may release some of the memory here to the system, and the corresponding allocated memory may be less than the amount allocated to it during initialization. The total allocated amount is greater than or equal to the amount of memory used.

Max : The maximum amount of memory that the memory management system can use. This value can be changed or not set. If the JVM tries to increase the used memory beyond the committed memory, the memory allocation may fail, even if the desired memory is less than or equal to the maximum (eg when the system virtual memory is low)

Usage Threshold The usage threshold of a memory pool. This field will only be shown if the memory pool supports usage threshold.
GC time : The total time used by garbage collection and the number of times garbage collection was called. It may have several lines, each representing the garbage collection algorithm used by the JVM. (

The bar graph in the lower right corner shows the memory consumed by the JVM's memory pool. If memory usage exceeds the usage threshold, the bar will turn red. usagethreshold is an attribute of the Memory Pool MBean used to support memory checking. MemoryPoolMXBean defines a series of methods for checking memory.
public interface MemoryPoolMXBean {
....
// Usage threshold
public long getUsageThreshold();
public void setUsageThreshold(long threshold);
public boolean isUsageThresholdExceeded();
public boolean isUsageThresholdSupported();
// Collection usage threshold
public long getCollectionUsageThreshold();
public void setCollectionUsageThreshold(long threshold);
public boolean isCollectionUsageThresholdSupported();
public boolean isCollectionUsageThresholdExceeded();
}

Each memory pool may have two types of memory initial support: usage threshold and collection usage threshold. Special memory pools may not support either.

Usage Threshold

The usage threshold is a manageable property of the memory pool. It uses low-load memory monitoring. Set the usage threshold to a positive value to check the memory pool. Setting the usage threshold to zero turns off checking. The default value is set by the JVM. The JVM generally sets the usage threshold to check memory at the most appropriate time, typically during the GC process and when some memory is allocated. If the JVM finds that the current memory usage exceeds the usage threshold, it will set the property to true . Some memory pools may not support the usage threshold. You can use usage threshold. For example, with a generational garbage collector (such as the HotSpot virtual machine), most of the objects are allocated in the young generation, from the eden memory pool. The eden pool is designed to be full; performing a garbage collection in the eden pool will free itUsageThresholdExceeded
UsageThresholdSupported属性来判断一个内存池是否支持

 

Collection Usage Threshold

Collection usage threshold is a configurable property of the memory pool that can be garbage collected. After the JVM heaps a memory pool for garbage collection, some memory in this memory pool is still occupied by objects that have not been collected. The collection usage threshold only allows you to check memory after garbage collection. If the JVM finds that the available memory exceeds the collection usage threshold, it will set CollectionUsageThresholdExceededthe property to true.
You can use CollectionUsageThresholdSupportedproperties to control memory pool release support for collection usage threshold.
usage threshold and collection usage threshold are a set of MBean tags. For example, select TenuredGen in the tree structure on the left, and set the usage threshold of the tenured generation memory pool to 6m. As shown below

Figure 6: Setting Usage Threshold.

When TenuredGenthe memory usage of the memory pool exceeds 6MBytes, TenuredGenthe histogram representing the memory pool will turn red to indicate that the memory used exceeds the usage threshold. The bar graph representing heap memory will also turn red. You can select the bar graph or specify memory pools in the graph to view information about a specific memory pool. If you put the mouse on the house bar graph, the name of the memory pool will be displayed

 

Figure 7: Low Memory.

Turn on/off verbose tracing of virtual machines

As mentioned above, the memory system MBean defines a boolean variable called Verbose that allows you to dynamically turn on or off detailed GC tracing. Detailed GC traces will be displayed when the JVM starts. The default HotSpot GC verbose output is stdout.

Figure 8: Setting Verbose GC.

 

 

deadlock check

The Threads tab provides information about the application's threads running

Figure 9: Threads Tab.

All running threads are listed in the lower left corner. If you enter a character in the filter, the thread list will only show threads whose thread names contain the character you entered. By clicking on a thread, you can get information about that thread.

The thread's MBean tag provides some useful operations that the Thread tag does not.

• findMonitorDeadlockedThreads. If a thread deadlock occurs, you can check it out through this. Operation returns a set of deadlocked thread IDs
• getThreadInfo. Returns thread information. Including the name of the thread, stack information, the lock that caused the current thread to block, if any, which thread holds the lock, and the statistics of the thread information.
• getThreadCpuTime.Returns the CPU time consumed by the specified thread.

To use these properties, go to the MBeans tab and select the Threading MBean in the MBeans tree. It lists operations for all properties of the currently monitored JVM.

Figure 10: MBeans Tab Threading.

To check if your app is in a deadlock (for example, your app hangs), you can use findMonitorDeadlockedThreadsactions.

Figure 11: Find Deadlocked Threads.

Once you have selected the findMonitorDeadlockedThreadsbutton, there will be a popup showing the results. In the above example, JConsole is connected to a sample application SampleTest with 3 deadlocked threads. As shown above, the threads with IDs 12, 10 and 11 are checked for deadlock. To query more thread information, you can use getThreadInfooperations. A thread's MBean supports getThreadInfofour forms of operations,

• Gives the deepest stack condition for a given thread ID
• heap a sequence of thread IDs, giving the deepest stack case

• Of a given thread ID with no stack trace.
• Of an array of thread IDs with no stack trace.

Corresponding to the deadlock situation, you will generally compare the relational stack situation. You can enter the thread ID of the deadlock and the stack depth you want to trace in the first parameter of the getThreadInfo operation.

Figure 12: ThreadInfo for Thread ID = 12.

Double-clicking on the value field of the stackTrace property will display a composite dialog where you can go back and forth in the stack. Figures 13, 14 show the first and second stack levels in the composite dialog for deadlocked thread-1.

Figure 13: Top Frame of the Stack Trace of DeadlockedThread-1.

Figure 14: Second Frame of the Stack Trace of DeadlockedThread-1.

The Threads tab provides a friendly interface for viewing thread stacks. You can find the name of the deadlocked thread using to getThreadInfofind thread information. You can then use the Threads tab to analyze deadlocks.

 

 

control log level

The Logging MBean defines LoggerNamesproperties that describe the log name. To find your application's logs, select 在MBeans树中java.util.loggingthe Logging MBean under , double-click the LoggerNames property

Figure 15: List of All Logger Names.

The Logging MBean also supports three operations:

• getParentLoggerName. Returns the parent logger of the specified logger
• getLoggerLevel. Returns the log level of the specified logger
• setLoggerLevel.set the specified logger to a new level

All three operations take the log name as the first argument.

Figure 16: Setting Log Level.

 

Get operating system resource information - extension under Sun platform

JDK5.0 extends the MBean of the operating system, so that you can obtain information about system resources, such as:

• Processing CPU
• total and free physical memory
• Available virtual memory. (i.e. virtual memory guaranteed to be allocated to a running process)
• total and free swap area
• Total number of open files (only available under Unix)

When you open the Operating System MBean under the MBeans tab, you can see all the properties and operations that the platform can perform. You can monitor any property over time - eg, CPU time - by double-clicking on the value range portion of the property.

Figure 17: MBeans Tab OS.

In addition to this, VM tags and Summary tags provide some information about operating system resources

 

The MBean of the Management Application The
Monitored SampleTest application has its own Hello MBean:

com.sun.example:type=Hello
If the CacheSize property changes, the Hello MBean will send a notification.
You can use the MBeans tab to manage your application's MBeans in the same way you manage the platform's MBeans.
For example, you want to monitor when the CacheSize property changes. you can first
Subscribe in the Notification tab. If you change the CacheSize, you can see a notification being sent.

Figure 18: Notifications.

 

Related Information

• Monitoring and Management for the Java Platform
• Monitoring and Management Tools

JProfiler trial notes

    JProfiler is a Java performance monitoring tool. You can view the current application's objects , object references, memory, CPU usage , threads, and thread operation (blocking, waiting, etc.) , that is: which method takes up more CPU resources. I am using version 4.3.2. I have tried version 3** before, but it has many bugs and is easy to die. Version 4** is much more stable.

     With the above information, it will be very helpful for system tuning. Here are a few articles for reference: Getting, Introduction , Getting Started , Solving Practical Problems with JProfiler . These articles have basically introduced common things, and let’s talk about some ideas below.

1. JProfiler monitoring consumes system resources, so in general, it should not be used for monitoring during performance testing.
2. If you want to use it in a relatively high pressure situation, you can selectively open the monitoring items, not all of them. There are two main ones, one is memory monitoring, which can find memory allocation hotspots when it is turned on. One is CPU monitoring, you can view the CPU usage hotspot when it is turned on. As shown in the picture, the red pen marks the part . If both are closed, you can still run under a certain amount of pressure, and you can also monitor the number of objects.
   
3. Personally think that the best (and the most used) is to query the current number of objects. Quantity monitoring is very important. If you use a singleton, you will only see that one object exists. If there are too many, it means that there is a problem with the program. Similarly, if the application performs a series of operations, check whether the destroyed object still exists. If it is not released, it must consider whether there is a memory overflow.
4. JProfiler also provides a better tool for checking out of memory. He can look up the reference of an object, that is: when you find that an object that should be released has not been released, you can look at which instance is referencing it, and find the root and find the overflow point.
   The specific operation is as follows: Right-click the object you want to monitor in the "Memory Views" interface, and select the first item "Take Heap Snapshot for Selection". After the selection is completed, the "Heap Walker" interface will be entered. The interface provides several functions, select "References" will do. As shown in the figure:
5. JProfiler provides different observation granularities, providing monitoring of classes, packages, and J2EE components. At the same time, filters are also easy to use, and you can directly locate the packages or classes you care about.
6. There may be a certain time difference between the monitoring of JProfiler and the application, so sometimes you need to wait for the refresh to display the correct system status.