Pages

Thursday, March 29, 2012

Tricks for Debugging Liferay


  Here are a few tricks that I have come across that have proven to be pretty useful.

1. Monitoring Memory and CPU usage

This is pretty basic and is quite helpful in performance tests.  Monitoring these aspects will help determine if a system is memory-bound or CPU-bound.  For the memory bit, Sun provides a nice set of tools called jvmstat to watch how garbage collection is doing on your system.  If you see the GC running too often or collecting huge amounts of memory at a time, that probably means you need to fix your 
JVM parameters.  For the CPU bit, your operating system usually comes bundled with some kind of CPU usage monitor.  In the case of the Mac OS X/Linux/Unix breed, you can use iostat or vmstat.  For Windows, you can use the bundled administration tool called Performance Monitor.

2. Getting Thread Dumps

Now, if you think you are deadlocking somewhere or spending way too much time in certain blocks of code under load, a pretty useful test is to gather thread dumps of the JVM.  This will tell you what every thread on the portal is doing at a given point in time.  Not sure how to do this on Windows, but under Mac OS X/Linux/Unix, you can do a 
kill -3 <pid> and your portal's log file will now have a bunch of information on what each thread was doing at the moment in time.  Don't be afraid of this command -- it will not kill your server (unless, of course, you do a kill -9 <pid> or something like that... so don't http://www.liferay.com/html/js/editor/fckeditor/editor/images/smiley/msn/teeth_smile.gif).



3. Remote Debugging

So in this scenario, you are running your portal on server X and you have all your debugging tools on laptop Y.  Well, if using Tomcat, you can start your portal with the command 
catalina.sh jpda start and it will enable remote debugging.  Then, using Eclipse or another IDE on laptop Y, you can start the debugger and hook it into a remote Java application on localhost port 8000.  You can then step through code and set breakpoints as though you were debugging code on your own laptop.

Hope that helps.  And if all else fails, search the Internet -- it never lies.s

No comments:

Post a Comment