In complex Java applications performance problems can occur due to various factors. These problems should be detected and retaliatory actions performed. Monitoring the cpu usage (per core), the amount of total and free physical memory or the process cpu time are only a few points.
Monitoring should be possible with little impact on the design of the instrumented application. Instrumenting the VM would give us informations about such as the number of classes loaded, uptime of the JVM, the amount of memory consumed, number of threads running and deadlock detection. Another point would be the monitoring of the runtime stack.
It would be an advantage if the monitoring agent doesn't need to know anything about the application to instrument. Due to that, we would achieve an encapsulation. It should be considered in which intervals the monitoring happens and what the trigger is. The amount of the instrumentation should also be configurable (whole application or only pieces).
There are a few possible ways to achieve the points listed above. Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monitoring applications and for diagnosing common problems. The improvements include:
With this monitoring and management APIs it's possible to get extended informations about the VM such as current threads running, heap state or the memory usage. But there is one thing that can't be done with pure Java. That's where the JNI (Java Native Interface) comes into play. With the JNI it's possible to get informations like the cpu usage directly from the underlying OS.
ere are a few possible ways to achieve the points listed above. Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monitoring applications and for diagnosing common problems. The improvements include:
With this monitoring and management APIs it's possible to get extended informations about the VM such as current threads running, heap state or the memory usage. But there is one thing that can't be done with pure Java. That's where the JNI (Java Native Interface) comes into play. With the JNI it's possible to get informations like the cpu usage directly from the underlying OS.
The Java Management Extensions (JMX) API is a standard API for management and monitoring of local and remote applications, devices, services, and the Java virtual machine. JMX became a standard part of the Java platform in in J2SE 5.0. Using JMX technology, a given resource is instrumented by one or more Java objects known as Managed Beans (MBeans). These MBeans are registered in a core managed object server (MBean server) that acts as a management agent and can run on most devices enabled for the Java programming language.
JMX technology enables Java applications to be managed without heavy investment: A JMX technology agent can run on most Java technology-enabled devices, thus Java applications can become manageable with little impact on their design. A Java application simply needs to embed a managed object server and make some of its functionality available as one or several managed beans (MBeans) registered in the object server; that is all it takes to benefit from the management infrastructure.
The architecture of JMX is shown below:https://195.227.0.189/NovaSpy/attachment/wiki/NovaSpy/Conceptual/OSSensor/AbstractApproaches/jmx_architecture.jpg * At the instrumentation level components called MBeans provide the application-specific management information. The MBeans provide the essential visibility and control for managing applications.
The Java Native Interface is needed for getting informations like the cpu usage of der underlying OS. It's impossible querying for cpu usage with pure Java so we need to go through the JNI to call native methods. Getting the informations out of Windows it's needed to compile the DLLs with a C-Compiler and under Linux it's needed to compile the .so (shared objects) files.
The architecture of JNI is shown below:https://195.227.0.189/NovaSpy/attachment/wiki/NovaSpy/Conceptual/OSSensor/AbstractApproaches/jni_architecture.png
