USING JCONSOLE............................................................................................................................................................

2
Starting JConsole..................................................................................................................................................10
Connecting JConsole to the application for monitoring......................................................................................10
The JConsole interface.........................................................................................................................................12
Viewing Summary Information.............................................................................................................................12
Monitoring Memory Consumption.......................................................................................................................14
Monitoring Thread Use........................................................................................................................................17
Monitoring Class Loading....................................................................................................................................18
Monitoring and Managing MBeans......................................................................................................................19
Viewing VM Information......................................................................................................................................21
Using JConsole
JConsole is a JMX-compliant monitoring tool. It uses the extensive JMX instrumentation of the Java virtual machine
to provide information on performance and resource consumption of applications running on the Java platform.

You can use JConsole to monitor both local applications (those running on the same system as JConsole) and remote
applications (those running on other systems).

Note: Using JConsole to monitor a local application is useful for development and prototyping, but is not
recommended for production environments, because JConsole itself consumes significant system resources. Remote
monitoring is recommended to isolate the JConsole application from the platform being monitored.

Detail information and settings about Jconsole can be found at

http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

For any Query you can contact me at: brijesha@imail

Settings needed for monitoring local java application

To enable the JMX agent for local access, set this system property when you start the JVM or Java application:

com.sun.management.jmxremote

Setting this property registers the JVM instrumentation MBeans and publishes the RMI connector via a private
interface to allow JMX client applications to monitor a local Java platform, that is, a JVM running on the same
machine.

For example, to monitor the J2SE sample application Notepad:

cd %JDK_HOME%/demo/jfc/Notepad
java -Dcom.sun.management.jmxremote -jar Notepad.jar

or

cd %JDK_HOME%/demo/jfc/Notepad
javaw -Dcom.sun.management.jmxremote -jar Notepad.jar

where JDK_HOME is the directory where the JDK is installed.

This way you can run any java application (.jar or .class) and monitor it for resources (memory, threads etc).
Settings needed for monitoring remote Java application

To enable monitoring and management from remote systems, set this system property when you start the JVM:

com.sun.management.jmxremote.port=<specify portNum >

where portNum is the port number through which you want to enable JMX/RMI connections for monitoring
purpose. Be sure to specify an unused port number.

Disabling SSL

This will allow any user to connect to this application and start monitoring without SSL authentication.

If you need to disable SSL for remote monitoring, pass this parameter to JVM when it starts:

-Dcom.sun.management.jmxremote.ssl=false

Disabling Security

This will allow any user to connect to this application and start monitoring without any kind of authentication.

To disable both password authentication and SSL ( i.e no security), pass these parameters to JVM when it starts:

-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Monitoring Tomcat
To monitor Tomcat you need to provide following parameters to JVM when tomcat is started.

Setting for monitoring If Starting tomcat form Eclipse:

Stop tomcat if already running.

Go to window-> preferences ->

Select Tomcat -> JVM Setting

Click Add button under Append to JVM Parameters.

Provide following parameters in the Enter parameters box.

(Just Copy paste the below line in the Enter a JVM parameter box)

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
-Xmx512m
Click Apply.

Click OK.

Start the tomcat from Eclipse.

Start Jconsole and start monitoring.

Setting for monitoring If Starting tomcat from command prompt using java or javaw:
Stop tomcat if already running.

Run the following command from command prompt.

javaw -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099

-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
-Xmx512m -jar bootstrap.jar start

or

java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099

-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
-Xmx512m -jar bootstrap.jar start

This will start tomcat in monitoring-enabled mode.

Note: Javaw will run tomcat in background and command prompt will return and will not show the
tomcat messages. While using java command, prompt will display tomcat messages on command prompt.

Using Javaw
Using java

Note: If you use java command to start tomcat you may not be able to access your tomcat application
(Html, jsp pages) from other machine (where your tomcat server is not running). In that case use javaw
command to start tomcat.

To stop the tomcat run the following command:

javaw -jar bootstrap.jar stop

or

java -jar bootstrap.jar stop

Starting JConsole
The jconsole executable is in JDK_HOME/bin, where JDK_HOME is the directory where the JDK is installed. If
this directory is on your system path, you can start the tool by simply typing jconsole in a command (shell)
prompt. Otherwise, you have to type the full path to the executable file.

Connecting JConsole to the application for monitoring

Connection to local Java application

Run JConsole from JDK_HOME/bin.

The local tab lists any JVMs running on the local system with monitoring enabled, select the application you want to
monitor, then click Connect.

Note: Tomcat application will be displayed with name similar to bootstrap.jar or

org.apache.catalina.startup.Bootstrap

Not: If your java application is not listed in the list please run the application applying the setting properly as
shown above.
Connection to Remote Java application or remote tomcat JVM for monitoring

Run JConsole from JDK_HOME/bin.

Click Remote tab option.

Enter Host name: name of the machine on which the JVM is running.

Enter Port number: the JMX agent port number you specified as shown above when you started the JVM.

User name and password are not required if security is disabled as shown above, else you need to provide username
and password, as per your parameters for JVM.
The JConsole interface
The jconsole interface is composed of six tabs:

• Summary tab: displays summary information on the JVM and monitored values.
• Memory tab: displays information on memory use.
• Threads tab: displays information on thread use.
• Classes tab: displays information on class loading
• MBeans tab: displays information on MBeans
• VM tab: displays information on the JVM

The following sections provide information on each tab.

Viewing Summary Information

The Summary tab displays some key monitoring information on thread usage, memory consumption, and class
loading, plus information on the JVM and operating system.
Summary
• Uptime: how long the JVM has been running
• Total compile time: the amount of time spent in just-in-time (JIT) compilation.
• Process CPU time: the total amount of CPU time consumed by the JVM

Threads
• Live threads: Current number of live daemon threads plus non-daemon threads
• Peak: Highest number of live threads since JVM started.
• Daemon threads: Current number of live daemon threads
• Total started: Total number of threads started since JVM started (including daemon, non-daemon, and
terminated).

Memory
• Current heap size: Number of Kbytes currently occupied by the heap.
• Committed memory: Total amount of memory allocated for use by the heap.
• Maximum heap size: Maximum number of Kbytes occupied by the heap.
• Objects pending for finalization: Number of objects pending for finalization.
• Garbage collector information: Information on GC, including the garbage collector names, number of
collections performed, and total time spent performing GC.

Classes
• Current classes loaded: Number of classes currently loaded into memory.
• Total classes loaded: Total number of classes loaded into memory since the JVM started, included those
subsequently unloaded.
• Total classes unloaded: Number of classes unloaded from memory since the JVM started.

Operating System
• Total physical memory: Amount of random-access memory (RAM) that the OS has.
• Free physical memory: Amount of free RAM the OS has.
• Committed virtual memory: Amount of virtual memory guaranteed to be available to the running process.
Monitoring Memory Consumption
The Memory tab provides information on memory consumption and memory pools.

The chart shows the JVM's memory use versus time, for heap and non-heap memory, and for specific memory
pools. The memory pools available depend on the JVM being used. For the HotSpot JVM, the pools are:

• Eden Space (heap): pool from which memory is initially allocated for most objects.
• Survivor Space (heap): pool containing objects that have survived GC of eden space.
• Tenured Generation (heap): pool containing objects that have existed for some time in the survivor space.
• Permanent Generation (non-heap): holds all the reflective data of the virtual machine itself, such as class
and method objects. With JVMs that use class data sharing, this generation is divided into read-only and
read-write areas.
• Code Cache (non-heap): HotSpot JVM also includes a "code cache" containing memory used for
compilation and storage of native code.

For more information on these memory pools, see Garbage Collection.

The Details area shows several current memory metrics:

 • Used: the amount of memory currently used. Memory used includes the memory occupied by all objects
including both reachable and unreachable objects.
• Committed: the amount of memory guaranteed to be available for use by the JVM. The amount of
committed memory may change over time. The Java virtual machine may release memory to the system
and committed could be less than the amount of memory initially allocated at startup. Committed will
always be greater than or equal to used.

• Max: the maximum amount of memory that can be used for memory management. Its value may change or
be undefined. A memory allocation may fail if the JVM attempts to increase the used memory to be greater
than committed memory, even if the amount used is less than or equal to max (for example, when the
system is low on virtual memory).

The bar chart at the lower right shows memory consumed by the memory pools in heap and non-heap memory. The
bar will turn red when the memory used exceeds the memory usage threshold. You can set the memory usage
threshold through an attribute of the MemoryMXBean.

Heap and Non-heap Memory

The JVM manages two kinds of memory: heap and non-heap memory, both created when it starts.
Heap memory is the runtime data area from which the JVM allocates memory for all class instances and arrays. The
heap may be of a fixed or variable size. The garbage collector is an automatic memory management system that
reclaims heap memory for objects.

Non-heap memory includes a method area shared among all threads and memory required for the internal processing
or optimization for the JVM. It stores per-class structures such as a runtime constant pool, field and method data,
and the code for methods and constructors. The method area is logically part of the heap but, depending on
implementation, a JVM may not garbage collect or compact it. Like the heap, the method area may be of fixed or
variable size. The memory for the method area does not need to be contiguous.

In addition to the method area, a JVM implementation may require memory for internal processing or optimization
which also belongs to non-heap memory. For example, the JIT compiler requires memory for storing the native
machine code translated from the JVM code for high performance.

Memory Pools and Memory Managers

Memory pools and memory managers are key aspects of the JVM memory system.

A memory pool represents a memory area that the JVM manages. The JVM has at least one memory pool and it may
create or remove memory pools during execution. A memory pool can belong to either heap or non-heap memory.
A memory manager manages one or more memory pools. The garbage collector is a type of memory manager
responsible for reclaiming memory used by unreachable objects. A JVM may have one or more memory managers.
It may add or remove memory managers during execution. A memory pool can be managed by more than one
memory manager.

Garbage Collection
Garbage collection (GC) is how the JVM frees memory occupied by objects that are no longer referenced. It is
common to think of objects that have active references as being "alive" and un-referenced (or unreachable) objects
as "dead." Garbage collection is the process of releasing memory used by the dead objects. The algorithms and
parameters used by GC can have dramatic effects on performance.

The HotSpot VM garbage collector uses generational garbage collection. Generational GC takes advantage of the
observation that, in practice, most programs create:

• many objects that have short lives (for example, iterators and local variables).
• some objects that have very long lifetimes (for example, high level persistent objects)
So, generational GC divides memory into several generations, and assigns each a memory pool. When a generation
uses up its allotted memory, the VM performs a partial garbage collection (also called a minor collection) on that
memory pool to reclaim memory used by dead objects. This partial GC is usually much faster than a full GC.

The HotSpot VM defines two generations: the young generation (sometimes called the "nursery") and the old
generation. The young generation consists of an "eden space" and two "survivor spaces." The VM initially assigns
all objects to the eden space, and most objects die there. When it performs a minor GC, the VM moves any
remaining objects from the eden space to one of the survivor spaces. The VM moves objects that live long enough in
the survivor spaces to the "tenured" space in the old generation. When the tenured generation fills up, there is a full
GC that is often much slower because it involves all live objects. The permanent generation holds all the reflective
data of the virtual machine itself, such as class and method objects.

As explained in the following documents, if the garbage collector has become a bottleneck, you can improve
performance by customizing the generation sizes. Using jconsole, explore the sensitivity of your performance metric
to the garbage collector parameters. For more information, see:

• Tuning Garbage collection with the 5.0 HotSpot VM

Monitoring Thread Use
The Threads tab provides information on thread use.

The Threads list in the lower left lists all the active threads. If you enter a string in the Filter field, the Threads list
will show only those threads whose name contains the string you enter. Click on the name of a thread in the Threads
list to display information about that thread to the right, including the thread name, state, and stack trace.
The chart shows the number of live threads versus time. Three lines are shown:

• Magenta: total number of threads

• Red: peak number of threads
• Blue: number of live threads.

See java.lang.Thread for more information about threads and daemon threads.
Monitoring Class Loading
The Classes tab displays information on class loading.

The graph plots the number of classes loaded versus time:

• Red line is the total number of classes loaded (including those subsequently unloaded).
• Blue line is the current number of classes loaded.

The Details section at the bottom of the tab displays the total number of classes loaded since the JVM started, the
number currently loaded and the number unloaded.
Monitoring and Managing MBeans
The MBean tab displays information on all the MBeans registered with the platform MBean server.

The tree on the left shows all the MBeans, organized according to their objectNames. When you select an MBean in
the tree, its attributes, operations, notifications and other information is displayed on the right.
You can set the value of attributes, if they are writeable (the value will be displayed in blue). You can also invoke
operations displayed in the Operations tab.
Displaying a Chart

You can display a chart of an attribute's value versus time by double-clicking on the attribute value. For example, if
you click on the value of the CollectionTime property of java.lang.GarbageCollector.Copy MBean, you will see a
chart that looks something like this:
Viewing VM Information
The VM tab provides information on the JVM.

The information includes:

• Uptime: Total amount of time since the JVM was started.

• Process CPU Time: Total amount of CPU time that the JVM has consumed since it was started.
• Total Compile Time: Total accumulated time spent in just-in-time (JIT) compilation. The JVM
implementation determines when JIT compilation occurs. The Hotspot VM uses adaptive compilation, in
which the VM launches an application using a standard interpreter, but then analyzes the code as it runs to
detect performance bottlenecks, or "hot spots".