1 / 19

The Heart Of The Matter

The Heart Of The Matter. The Java Virtual Machine Mike Brunt. The Heart Of The Matter - JVM. What is the JVM? Main JVM Suppliers ColdFusion and the JVM Java J2EE – Java EE Servlet Containers Where everything sits-fits Tuning the JVM Metrics Logging

gisela
Download Presentation

The Heart Of The Matter

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Heart Of The Matter The Java Virtual Machine Mike Brunt

  2. The Heart Of The Matter - JVM • What is the JVM? • Main JVM Suppliers • ColdFusion and the JVM • Java J2EE – Java EE Servlet Containers • Where everything sits-fits • Tuning the JVM • Metrics Logging • Using utilities to aid in tuning the JVM • References • Summary

  3. What is the JVM? • Sun Microsystems created Java as a high-level programming language which should run on as many operating systems and hardware variations as possible. The goal of “write once run anywhere” meant that a predictable encapsulated operating system, no matter what the underlying hardware and software, was required. • The Java Virtual Machine (JVM or JRE) is a multi-threaded environment abstracting the actual computer operating system from the application code.

  4. Main JVM Suppliers • These are the main suppliers of Java Virtual Machines, there are others. • Sun Hotspot JVM • IBM JVM • BEA JRockit • MAC OSRuntime for OSX • Oracle JVM aka JServer – OJVM • Microsoft JVM

  5. ColdFusion and the JVM • Since ColdFusion MX 6.0-6.1, CF has been a Java Application which needs what is known as a Servlet Container to run on. The most popular Servlet Container for ColdFusion is JRun. • In the Enterprise edition of ColdFusion, the actual Servlet Container to be used can be selected during the install. In non-Enterprise installs JRun is automatically used. The main point being that there is always a Servlet Container.

  6. Java J2EE – Java EE Servlet Containers • This is a list 0f Java Servlet Containers which are certified as fully J2EE – Java EE compliant by Sun Microsystems. • Geronimo from Apache • JBoss from Red Hat • JRun from Adobe • Oracle OC4J • Sun Java System Application Server (Sun One). • WebLogic Server from BEA • WebSphere Server from IBM

  7. Where everything sits-fits • This is a simple diagram showing where the Operating System, JVM, Servlet Container and Java Application Server sit in relativity.

  8. ColdFusion and the JVM • Standard-Server • Enterprise Windows Install Windows Install

  9. ColdFusion and the JVM • This is a simple diagram showing where the Operating System, JVM, Servlet Container and Java Application Server sit in relativity.

  10. Tuning the JVM • Garbage Collectors • Garbage Collectors (different arguments to jvm.config) • -XX:+UseParallelGC Use parallel garbage collection, this is typically the default collector for ColdFusion installations. This collector is also referred to as the throughput collector. It uses a parallel version of the young generation collector. The old (tenured) generation is still cleaned with the default collector. Note This option can not be used in conjunction with -XX:+UseConcMarkSweepGC. • -XX:+UseConcMarkSweepGC Use concurrent garbage collection. This collector is also referred to as the concurrent low pause collector. It collects garbage in the old (tenured) generation concurrently to executing the application. Note that this option can not be used in conjunction with -XX:+UseParallelGC. Instead you may combine it with -XX:+UseParNewGC • -XX:+UseParNewGC Instructs the VM to use a parallel collector for the young generation. This option can be used in conjunction with -XX:+UseConcMarkSweepGC. • * As a note I have found that using the ConcMarkSweepGC along with ParNewGC can cause longer Full GC’s, I tend to use ParNewGC on it’s own.

  11. Tuning the JVM • Full Garbage Collections – Minimize • Sun JVM’s use a generational garbage collector with two young generations and an old generation. New objects are always allocated in the young generation part of the heap. Every time the young generation is full a minor garbage collection takes place. Minor garbage collections don't take very long. • Objects which survived some minor collections, because they are still referenced from the application, are promoted to the older generation. Usually the older generation is full at some point too, and needs to be cleaned. This leads to a major garbage collection or Full Garbage (Full GC) collection that removes garbage from both the old and the younger generations. Full GC’s are “stop-the-world” events and need to occur only when absolutely necessary.

  12. Tuning the JVM • Full Garbage Collections – Minimize • One of the first methods I always want to employ when troubleshooting is to ascertain how many Full GC’s are taking place. To do so I add these arguments to the jvm.config file, which is located in one of these directories depending on the installation: • Enterprise – {drive-volume}\jrun4\bin • Standard/Server - {drive-volume}\CFusionMX7\runtime\bin -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -verbose:gc -Xloggc:yourname.log* *This will send Garbage collection output to the {std}-out.log and will create a log of all GC activity with whatever name you gave yourname in either.. • Enterprise – {drive-volume}\jrun4\bin • Standard/Server - {drive-volume}\CFusionMX7\runtime\bin

  13. Tuning the JVM • Full Garbage Collections – Minimize • Here is an example of the Verbose Garbage Collection log output… par new generation total 97088K, used 0K [0x10010000, 0x171d0000, 0x171d0000) eden space 77696K, 0% used [0x10010000, 0x10010000, 0x14bf0000) from space 19392K, 0% used [0x14bf0000, 0x14bf0000, 0x15ee0000) to space 19392K, 0% used [0x15ee0000, 0x15ee0000, 0x171d0000) tenured generation total 932096K, used 11109K [0x171d0000, 0x50010000, 0x50010000) the space 932096K, 1% used [0x171d0000, 0x17ca95b8, 0x17ca9600, 0x50010000) compacting perm gen total 26624K, used 26606K [0x50010000, 0x51a10000, 0x58010000) the space 26624K, 99% used [0x50010000, 0x51a0b8a0, 0x51a0ba00, 0x51a10000) } , 0.1523967 secs] 3691.704: [Full GC{Heap before GC invocations=8: Heap • This Full GC was almost certainly unnecessary because at the time it ran only 1109k out of 932096k of the tenured (old) generation had been used. I also note the timestamp (3691.704) of every Full GC in the log. If I see a regular pattern it almost always means something is calling a Full GC perhaps using system.gc()

  14. Tuning the JVM • Full Garbage Collections – Minimize – How? • One pattern I have seen over and over with ColdFusion is that Full GC’s are very often occurring at regular 60 second intervals. Although I have never been able to pin this down fully, I suspect it is due to a Java process called RMI(Remote Method Invocation). So then what do we do to control these unnecessary “stop-the-world” Full GC’s? There are two alternatives… • 1/ Disable Full GC’s using the -XX:+DisableExplicitGC jvm.config argument. I am not totally happy doing this and in many cases it will not work • 2/ Run Full GC’s at longer regular intervals. Applying these arguments instead of -XX:+DisableExplicitGC will cause Full GC’s every 10 minutes (600,000 ms). -Dsun.rmi.dgc.client.gcInterval=600000-Dsun.rmi.dgc.server.gcInterval=600000

  15. Metrics Logging • I have found that enabling metrics looking is invaluable in troubleshooting ColdFusion and JRun application issues. Metrics logging will show the status of the CF-JRun instance at pre-selected time intervals in terms of number of threads in use and available memory. In order to enable metrics logging we need to edit the jrun.xml file, here… • Enterprise install {drive-volume}\JRun4\servers\{servername}\SERVER-INF Server-Standard install {drive-volume} \CFusionMX7\runtime\servers\{servername}\SERVER-INF • Setting detail is on the next slide

  16. Metrics Logging • Here is how to enable metrics logging in the jrun.xml file • Firstly uncomment the service class… • Then set “metricsEnabled” to true, we will leave other settings to default. • Lastly I like to spilt the logs out to make reading them easier by this change

  17. References • Sun JVM Versions up to 1.5 (5.0) http://java.sun.com/j2se/codenames.html • GC Viewer Tool (Sun JVM up to 1.4x) http://www.javaperformancetuning.com/tools/gcviewer/index.shtml

  18. Summary • I have found that the only way to really determine the correct garbage collector to use for your applications and what the correct arguments are to pass to the JVM, via the jvm.config file, to effectively manage garbage collections is to first determine how many Full GC’s are occurring and control that if there are too many. Then load-test the application whilst tuning the arguments passed to the JVM, via the jvm.config file.

  19. The Heart Of The Matter -Presenter Mike Brunt mbrunt@go2ria.net

More Related