Wednesday, December 01, 2010

Diagnosing Web Application OutOfMemoryErrors

http://www.infoq.com/presentations/Diagnosing-Memory-Leaks

Tips:


Common causes for perm gen memory leaks in a webserver application are registries holding multiply loaded classes from logging, JDBC drivers, GWT, causing references to be retained to the web application class loaders.







Process heap consists of: Perm Gen, Thread Stacks, native Code, compiler, GC, heap (young and old gens).






Class objects are loaded into PermGen






Common OutOfMemoryErrors that are not memory leaks: too many classes (increase perm gen); too many objects (increase heap or decrease objects/object sizes); stack overflow (reduce/alter recursion or increase stack size).






Memory leaks are indicated by steady increases in memory, and more frequent GC; however these can also be normal to the system so just indicators.






Apart from gross heap sizes, different garbage collector algorithms need to be tuned differently. The default is probably a good starting point.






In tomcat, putting a JDBC driver into the WEB-INF/lib directory can cause a memory leak (use common/lib and there is no leak) of web application loaders being pinned in memory - reloading causes the actual leak. Look for instances of the web application classloaders - there should be one per application, any extra are a memory leak (the leaks will have a "started" field set to false). Find the roots and see what is keeping it alive.






Finding the reference holding memory on reloads in tomcat web applications is straightforward, but this doesn't tell you how that reference was populated, for that you need allocation stack traces - which is horrendously expensive, so can only be done in debug mode.




No comments: