2

Let's say I have a very large Java application that's deployed on Tomcat. Over the course of a few weeks, the server will run out of memory, application performance is degraded, and the server needs a restart.

Obviously the application has some memory leaks that need to be fixed.

My question is.. If the application were deployed to a different server, would there be any change in memory utilization?

Michael
  • 7,348
  • 10
  • 49
  • 86
schottsfired
  • 131
  • 5

2 Answers2

3

Certainly the services offered by the application server might vary in their memory utilization, and if the server includes its own unique VM -- i.e., if you're using J9 or JRockit with one server and Oracle's JVM with another -- there are bound to be differences. One relevant area that does matter is class loading: some app servers have better behavior than others with regard to administration. Warm-starting the application after a configuration change can result in serious memory leaks due to class loading problems on some server/VM combinations.

But none of these are really going to help you with an application that leaks. It's the program using the memory, not the server, so changing the server isn't going to affect much of anything.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
  • 1
    +1 for the last paragraph. Changing to a different web container is highly unlikely to fix the webapp's storage leaks. – Stephen C May 09 '12 at 02:57
  • True, but at least Tomcat 7 has better memory leak detection. :) – Michael May 10 '12 at 09:08
  • "It's the program using the memory not the server." I completely agree, and this makes perfect sense. But.. does the application server hook into the JVM and affect the GC behavior? – schottsfired May 14 '12 at 23:55
  • 1
    Usually the app server provides startup scripts that launch the JVM, so yes, those scripts absolutely could pass GC configuration options to the JVM; plus, as I said, some servers have their own JVM implementation that would have different overall behavior. – Ernest Friedman-Hill May 15 '12 at 00:01
2

There will probably be a slight difference in memory utilisation, but only in as much as the footprint differs between servlet containers. There is also a slight chance that you've encountered a memory leak with the container - but this is doubtful.

The most likely issue is that your application has a memory leak - in any case, the cause is more important than a quick fix - what would you do if the 'new' container just happens to last an extra week etc? Moving the problem rarely solves it...

You need to start analysing the applications heap memory, to locate the source of the problem. If your application is crashing with an OOME, you can add this to the JVM arguments.

-XX:-HeapDumpOnOutOfMemoryError

If the performance is just degrading until you restart the container manually, you should get into the routine of triggering periodic heap dumps. A timeline of dumps is often the most help, as you can see which object stores just grow over time.

To do this, you'll need a heap analysis tool:

JHat or IBM Heap Analyser or whatever your preference :)

Also see this question:

Recommendations for a heap analysis tool for Java?

Update:

And this may help (for obvious reasons):

How do I analyze a .hprof file?

Community
  • 1
  • 1
Michael
  • 7,348
  • 10
  • 49
  • 86
  • I've seen this java option before. Does the heap dump get stored in a file, then opened in one of the analysis tools? – schottsfired May 14 '12 at 23:56
  • 1
    Yes, normally with a .hprof file extension. Learning to interpret the results is a bit of an art form though. – Michael May 15 '12 at 08:33