Grails application hogging too much memory

Tomcat 5.5.x and 6.0.x

Grails 1.6.x

Java 1.6.x

OS CentOS 5.x (64bit)

VPS Server with memory as 384M

JAVA_OPTS : tried many combinations- including the following

export JAVA_OPTS='-Xms128M -Xmx512M -XX:MaxPermSize=1024m'

export JAVA_OPTS='-server -Xms128M -Xmx128M -XX:MaxPermSize=256M'

(As advised by http://www.grails.org/Deployment)

I have created a blank Grails application i.e simply by giving the command grails create-app and then WARed it

I am running Tomcat on a VPS Server

When I simply start the Tomcat server, with no apps deployed, the free memory is about 236M and used memory is about 156M

When I deploy m开发者_JS百科y "blank" application, the memory consumption spikes to 360M and finally the Tomcat instance is killed as soon as it takes up all free memory

As you have seen, my app is as light as it can be.

Not sure why the memory consumption is as high it is.

I am actually troubleshooting a real application, but have narrowed down to this scenario which is easier to share and explain.

UPDATE I tested the same "blank" application on my local Tomcat 5.5.x on Windows and it worked fine

The memory consumption of the Java process shot from 32 M to 107M. But it did not crash and it remained under acceptable limits

So the hunt for answer continues... I wonder if something is wrong about my Linux box. Not sure what though...

UPDATE 2 Also see this http://www.grails.org/Grails+Test+On+Virtual+Server

It confirms my belief that my simple-blank app should work on my configuration.

It is a false economy to try to run a long running Java-based application in the minimal possible memory. The garbage collector, and hence the application will run much more efficiently if it has plenty of regular heap memory. Give an application too little heap and it will spend too much time garbage collecting.

(This may seem a bit counter-intuitive, but trust me: the effect is predictable in theory and observable in practice.)

EDIT

In practical terms, I'd suggest the following approach:

1. Start by running Tomcat + Grails with as much memory as you can possibly give it so that you have something that runs. (Set the permgen size to the default ... unless you have clear evidence that Tomcat + Grails are exhausting permgen.)

2. Run the app for a bit to get it to a steady state and figure out what its average working set is. You should be able to figure that out from a memory profiler, or by examining the GC logging.

3. Then set the Java heap size to be (say) twice the measured working set size or more. (This is the point I was trying to make above.)

Actually, there is another possible cause for your problems. Even though you are telling Java to use heaps of a given size, it may be that it is unable to do this. When the JVM requests memory from the OS, there are a couple of situations where the OS will refuse.

• If the machine (real or virtual) that you are running the OS does not have any more unallocated "real" memory, and the OS's swap space is fully allocated, it will have to refuse requests for more memory.

• It is also possible (though unlikely) that per-process memory limits are in force. That would cause the OS to refuse requests beyond that limit.

Finally, note that Java uses more virtual memory that can be accounted for by simply adding the stack, heap and permgen numbers together. There is the memory used by the executable + DLLs, memory used for I/O buffers, and possibly other stuff.

384MB is pretty small. I'm running a small Grails app in a 512MB VPS at enjoyvps.net (not affiliated in any way, just a happy customer) and it's been running for months at just under 200MB. I'm running a 32-bit Linux and JDK though, no sense wasting all that memory in 64-bit pointers if you don't have access to much memory anyway.

Can you try deploying a tomcat monitoring webapp e.g. psiprobe and see where the memory is being used?