views:

405

answers:

3

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 my "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.

A: 

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.

Burt Beckwith
you mean enjoyvps.com- right? Just took a look. Looks neat ! Thanks for the tip. BTW, you agree that I should be able to run a blank grails app on a 384M as well- right ?
RN
Grails is a bit memory-hungry but I found that 1.2 helped a lot, especially since it precompiles GSPs when building the war so permgen usage at runtime is way down. But there's a lot of memory used by all those MetaClass instances, but that's the cost of the dynamic nature of Groovy and Grails. But while it should start up in 384MB, that doesn't leave much room to work.
Burt Beckwith
I don't mind adding more memory to my VPS if thats what it needs, but I am not convinced that I have hot the max yet. I mean the test app i am working with- has ZERO GSPs or domain classes !. Its as bare as a Grails app gets.
RN
+4  A: 

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.

Stephen C
Sorry. I am not sure if I completely followed you. Do you have advice on what I should change ?
RN
A: 

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

mojones
Will give it a shot !!!
RN