20
TEN THINGS GOOD TO KNOW ABOUT JVM WORKING WITH IBM BPM!!
1. What does JVM have to do with BPM?
BPM products are written in Java and run on Java. The IBM Java SDK/JRE is shipped within the WebSphere Application Server which is embedded with the BPM products. IBM develops JVM for Windows, Linux, AIX and z/OS operating systems. The performance of JVM is a crucial factor determining the performance of the BPM products. Java Platform Standard Edition (Java SE) 6 is shipped with WebSphere Application Server V7.0. Click here for a Java SE 6 overview.
The IBM-enhanced or "hybrid" SDK/JRE is shipped with products for Sun Solaris and HP-UX platforms. The "hybrid" is essentially a Sun Solaris or HP-UX Java package, with added IBM technology covering Security, ORB and XML and do not contain an IBM-developed JVM, but instead use the basic Sun/HP JVM unchanged.
2. How do I know the JVM version?
When you contact IBM Support for JVM related problems, you may be asked for the JVM version. The easiest and most convenient way of knowing the JVM version is to look in the SystemOut.log. The current environment display section will report the Java version. This is an extract from SystemOut.log from a Windows installation.
Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
This may not be sufficient when you report problems and to get a detailed version information run the command below:
[WebSphere Application Server Install Root]/java/jre/bin/java -version
D:\IBM\WID70_WTE\runtimes\bi_v7\java\jre\bin>java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260sr7ifix-20100220_01(SR7+IZ70326))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr7-201002
19_54049 (JIT enabled, AOT enabled)
J9VM - 20100219_054049
JIT - r9_20091123_13891
GC - 20100216_AA)
JCL - 20091202_01
3. Where do I find garbage collection logs, and why?
Garbage collection history is recorded in garbage collection logs, also known as verbosegc logs. This is crucial for JVM problems and a must have for troubleshooting most of the JVM problems. For operating systems using IBM JDK, the verbosegc log is written to native_stderr.log. For Sun Solaris or HP-UX Java package, the verbosegc is written to native_stdout.log.
The administrative console provides an option to enable verbosegc. Refer to the technote here for detailed steps.
When running stand-alone Java commands you can enable verbosegc using -verbosegc parameter. You can redirect output to a file using -Xverbogegclog:<filename>. A usage scenario for this command is when you face JVM issues running wsadmin command. You can edit the wsadmin script to add the parameters to the Java command.
Enabling verbosegc with the basic options produces very negligible performance impact to the running server processes. On the contrary, it is a very valuable troubleshooting aid in case of unexpected JVM problems.
4. Where do I see and set JVM properties?
At times, you might be required to modify JVM properties or add custom properties. The administrative console provides you options to specify these properties. The path is Servers -> Application Servers -> server_name -> Server Infrastructure -> Java and Process Management -> Process Definition -> Additional Properties -> Java Virtual Machine
Going for a 64-bit JVM has performance gains and loss. Read the WebSphere Application Server V7.0 64-bit performance paper here. There is also a slightly older (Java SE 5) WSTE Webcast on this topic here. There is also a porting guide for Java 64-bit here. Thanks to Michele Calcavecchia from the Support team for helping me find these.
6. What is an OutOfMemory error?
OutOfMemory error is a JVM error condition. It is caused either by Java heap running out of space to allocate any further objects, even after garbage collection, or by native memory running out of space in the JVM. Java heap outage can cause severe performance degradation of application performance or even outage. Native memory exhaustion can also be so severe that no native calls will be carried out, such as a call to create a new thread. OutOfMemory errors are usually caused by insufficient heap requirements or by a memory leak in software code.
7. What is a JVM crash?
Crash is a JVM error condition resulting in abrupt halt/termination of the JVM. Crashes can occur because of a JRE fault, because of a fault in native (JNI) code being run in the Java process, due to a resource outage such as memory, or a defect in JVM. A JVM crash usually creates a core dump on UNIX or userdump in Windows operating systems and a javacore file and SNAP trace on IBM JDKs.
For Sun Solaris and HP-UX operating systems an hs_err_pid*.log is created.
These files help in identifying the cause of the crash. It would be difficult reproducing crashes therefore note that you should not delete these crucial files from the original incident.
8. Heapdumps and javacores, What are these?
Heapdump is a dump of all the live objects that are on the Java heap. This is a compressed binary file of portable heap dump (phd) format. Heapdumps are enabled by default on an OutofMemory error by all JDKs. By default this gets generated in the <profile root> directory of the server JVM which reported the OutOfMemory.
Javacore or javadump or threaddump is a text file giving information that includes the Java threads present, the classes loaded, and heap statistics. It is automatically generated in the event of a JVM crash or OutOfMemory error. You would want to generate a javacore to see the threads in the JVM and their status anytime, especially for hang and high CPU usage scenarios. They can be triggered by user signal (kill -3) on UNIX or using wsadmin commands:
cmd>wsadmin
wasdmin>set jvm [$AdminControl completeObjectName type=JVM,process=%1,*] > %FILENAME%
wsadmin>$AdminControl invoke $jvm dumpThreads >> %FILENAME%By default this gets generated in the <profile root> directory of the server JVM, for IBM JDK. For Sun Solaris and HP-UX, the javacore is written to the native_stdout.log.
9. What IBM tools are available for JVM diagnostics?
Heapdump analysis:
Memory analyzer tool (here)
Memory Dump Diagnostic for Java (MDD4J) (here)
IBM HeapAnalyzer (here)Verbosegc log analysis:
IBM Garbage Collection and Memory Visualizer (here)
IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (here)Javacore analysis:
IBM Thread and Monitor Dump Analyzer for Java (here)and many more...
10. Where do I learn more about JVM?
There is more to the JVM than just being the runtime engine. You might be interested in knowing the garbage collection modes, policies, or the command line parameters for the JVM, or a diagnostic guide. The best resource to learn more about JVM is developerWorks Java technology: Diagnosis documentation here.
