Menu
In almost all larger Java projects I've been involved with I've noticed that the quality of service of the application degrades with the uptime of the container. This is most probably due to memory leaks in the code.
The correct way to solve this problem is obviously to trace back to the root cause of the problem and fix the leaks in the code. The quick and dirty way of solving the problem is simply restarting Tomcat (or whichever servlet container you're using).
These are my three questions:
Assume that you choose to solve the problem by tracing the root cause of the problem (the memory leaks), how would you collect data to zoom in on the problem?
Assume that you choose the quick and dirty way of speeding things up by simply restarting the container, how would you collect data to choose the optimal restart cycle?
Have you been able to deploy and run projects over an extended period of time without ever restarting the servlet container to regain snappiness? Or is an occasional servlet restart something that one has to simply accept?
710
In Java, the memory leak is a situation when the garbage collector does not recognize the unused objects and they remain in the memory indefinitely that reduces the amount of memory allocated to the application. Because the unused objects still being referenced that may lead to OutOfMemoryError.
Inexperienced programmers often think that Java's automatic garbage collection frees them from the burden of memory management. This is a common misperception: while the garbage collector does its best, it's entirely possible for even the best programmer to fall prey to crippling memory leaks.
Assume that you choose to solve the problem by tracing the root cause of the problem (the memory leaks), how would you collect data to zoom in on the problem?
Take a heap dump using jmap and load the dump using Eclipse Memory Analyzer. From there you can analyze which objects are eating up the most memory, which "roots" are preventing other objects from being collected, etc.
There are other heap analysis programs, such as jhat, but I've found EMA to be the fastest and best (free) solution.
Assume that you choose the quick and dirty way of speeding things up by simply restarting the container, how would you collect data to choose the optimal restart cycle?
Use JMX to monitor heap size and other heap and GC statistics.
Have you been able to deploy and run projects over an extended period of time without ever restarting the servlet container to regain snappiness?
Yes. By avoiding/fixing memory leaks.
141
even if your code has no real issues, there can be some memory leaks if you are using apache. check out http://www.tomcatexpert.com/blog/2010/04/06/tomcats-new-memory-leak-prevention-and-detection for tips and suggestions
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
