Friday, October 31, 2008

Tomcat Troubleshooting

The OMII-UK website is a Java web application running in Tomcat, which sits behind an Apache web server. Several methods are there for monitoring and troubleshooting it.


First, a simple web monintor is running on another machine, and checking the contents of several important web pages every 15 minutes. If anything goes wrong, I will get an email notification. Of course, this task can also be done by Nagios. The advantage of using my own web monitor instead of a complicated monitor system like Nagios, is that I have full control over what to inspect. For instance, I am able to detect that although Tomcat is still OK but the database connection is down.

Second, in the Java web applicaiton, which is based on the Spring Framework, Spring AOP (Aspect Oriented Programming) is leveraged to monitor the performance of all servlets. If it takes any servlet more than a pre-defined threshold to serve a request, I'll get an email notification. The threshold, currently set to 200ms, is defined in Spring XML configuration file.

Third, Tomcat is started with "", which enables local jconsole connection. JDK 1.5 is used. In JDK 1.6, jconsole support is default, so no need to set a JVM option to enable it.

What if something goes wrong ...
  1. Check Apache web server only. http://hostname/server-status. You may need to modify httpd.conf to enable this.
  2. Check Tomcat only. http://hostname:8080.
  3. Check jconsole->Memory. See if JVM runs out of memory.
  4. Check Tomcat logs, Apache logs and database log.
  5. Last but not least important, use Chainsaw to check log4j.xml. Chainsaw is a GUI, which makes it easy to browse log4j's log. The log4j configuration may look like:
log4j.appender.FileLog = org.apache.log4j.RollingFileAppender
log4j.appender.FileLog.MaxFileSize = 10MB
log4j.appender.FileLog.MaxBackupIndex = 14
log4j.appender.FileLog.layout = org.apache.log4j.xml.XMLLayout

Let's say there is a memory leak or something inside the Java web application is wrong ...

There are various JVM options that allow us to debug or profile Java web application:
  • Frequently used server VM options: -server -Xms512m -Xmx512m
  • jconsole support:
  • Dump heap on running out of memory: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/root/heapdump
  • Enable debugging: -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000
  • Enable YourKit profiling: -agentlib:yjpagent
YourKit is a very good Java profiling tool, and it has a free licence for open source projects. That is what I am using. To enable profiling manually, see here.
  • On Windows, 32-bit, add \bin\win32 to the (SYSTEM) PATH.
  • On Linux x86, 32-bit, add /bin/linux-x86-32 to the LD_LIBRARY_PATH.
  • Check whether it is working: java -agentlib:yjpagent=help
  • Profiling: java -agentlib:yjpagent
  • Do not forget to force garbage collection before capture memory.
I also have a stress test tool that replays saved Apache/Tomcat access logs.

1 comment:

Anonymous said...

It's not necessary to force GC before capturing of snapshot. YourKit Profiler itself invokes GC before memory snapshot.