I have recently been involved in implementing and testing our application in a high volume / high performance customer case, where I thought I might try using VisualVM to see the JVM in action and find potential bottlenecks, like where would most of the CPU usage would go (the module I’m writing is a big CPU hog) as well as maybe latency issues caused by inadequate garbage collector settings.
The screenshots below are taken from a much smaller test environment where I just ran a quick test, but I have been able to use the tool in the customer environment where we were able to identify occasional high CPU usage with garbage collection (the blue line in the CPU area, left) as well as OutOfMemory problems due to the default garbage collection strategies (notice the erratic/irregular shapes in heap usage on the right side) - both can be addressed by adjusting the garbage collector strategy for low pause, concurrency (using -XX:+UseConcMarkSweepGC and -XX:+UseParNewGC parameters, see "before" and "after" screenshots below).
Also we found high CPU usage on certain application threads that now we can focus to optimize the code in those areas, they are not part of these screenshots, but I might post separately on that. Also from the threads graph is visible we have a high number of threads with a short life span, probably around the JMS connectivity area that we’re still investigating.
I’m nowhere even close to being an expert on these things, I’m still learning the stuff, but since I struggled a bit to get the JMX enabled with JBoss 4.2.3, though I might share the findings others might find useful and why not even got some more qualified suggestions from you, the readers out there.
VisualVM seems to be quite a capable tool (not to mention easy on the eye), giving you real time information through the graphs, being able to take memory dumps to analyze offline (with say the likes of Eclipse Memory Analyzer), perform garbage collection, take thread dumps, look at active / dead threads or run a CPU sampler to see the top consumer threads.
.png)
.png)
The screenshots below are taken from a much smaller test environment where I just ran a quick test, but I have been able to use the tool in the customer environment where we were able to identify occasional high CPU usage with garbage collection (the blue line in the CPU area, left) as well as OutOfMemory problems due to the default garbage collection strategies (notice the erratic/irregular shapes in heap usage on the right side) - both can be addressed by adjusting the garbage collector strategy for low pause, concurrency (using -XX:+UseConcMarkSweepGC and -XX:+UseParNewGC parameters, see "before" and "after" screenshots below).
Also we found high CPU usage on certain application threads that now we can focus to optimize the code in those areas, they are not part of these screenshots, but I might post separately on that. Also from the threads graph is visible we have a high number of threads with a short life span, probably around the JMS connectivity area that we’re still investigating.
I’m nowhere even close to being an expert on these things, I’m still learning the stuff, but since I struggled a bit to get the JMX enabled with JBoss 4.2.3, though I might share the findings others might find useful and why not even got some more qualified suggestions from you, the readers out there.
- Visual
http://visualvm.java.net/ - Setting up JBoss for remote JMX
http://labs.consol.de/lang/de/blog/jmx4perl/jboss-remote-jmx/
wrapper.java.additional.14=-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl wrapper.java.additional.15=-Djboss.platform.mbeanserver wrapper.java.additional.16=-Dcom.sun.management.jmxremote wrapper.java.additional.17=-Dcom.sun.management.jmxremote.port=9999 wrapper.java.additional.18=-Dcom.sun.management.jmxremote.ssl=false wrapper.java.additional.19=-Dcom.sun.management.jmxremote.authenticate=falseOnce setup you can just run VisualVM and point it to localhost:9999 if you’re going to do the monitoring locally, although probably for a high performance environment you might want to run VisualVM from another machine, so it doesn’t affect the environment too much. Just as well, with the JMX enabled you can probably use that from a monitoring application and set warning thresholds for things like free JVM memory, high CPU usage etc.
VisualVM seems to be quite a capable tool (not to mention easy on the eye), giving you real time information through the graphs, being able to take memory dumps to analyze offline (with say the likes of Eclipse Memory Analyzer), perform garbage collection, take thread dumps, look at active / dead threads or run a CPU sampler to see the top consumer threads.
.png)
.png)
No comments :
Post a Comment