Robinson, Eric wrote:
If your application
needs 64MB of
Heap space and you allocate only -Xms16M, then right at the
start the
JVM will have to increase the Heap to 64MB (minimum); so
why would you
do that ?
64MB was just a number I threw out. The app actually uses about 20MB at
startup, so we might consider setting the minimum pool to 25M.
I can see the lure of "only taking what you need" and
allowing the JVM to automatically re-size the memory space:
that way, you only take up a huge chunk of memory during peak
load and not all the time.
But why?
If you are going to need, say, 512MiB at peak load, you're
going to need that memory available whether or not it is
allocated to the JVM itself at any given time. If that's the
case, why not let the JVM have that memory all the time?
Because the server has about 100 instances of tomcat. They do not all
need the memory at the same time.
Famous last words..
But if they ever do, you are going to experience random failures of your Tomcat instances,
or at the very least a dramatic drop in performance, when this starts to swap to disk.
We don't know what your precise circumstances are, and maybe your case is
special.
But in general, I would not recommend this as a way to run a production server.
Technically, you can do what you described. What results it will have in the practice,
you will find out.
Just to stress some points made earlier then :
- "Initial Memory pool" corresponds to the Java command-line parameter "-Xms"
and indicates the initial (and I believe minimum size) of the Java Heap.
- "Maximum Memory pool" corresponds to the Java command-line parameter "-Xmx"
and indicates the maximum size of the Java Heap.
(you will find a more complete list of options here :
http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html)
The heap is part of how much memory each of your Tomcat instances will need, but it is not
not all the memory that they will need.
If you are short of physical memory, you may want to have a look at running multiple
virtual <Host>'s inside of one Tomcat, rather than one Tomcat instance per
application/customer. Multiple <Host> inside Tomcat all share the same Tomcat code and
the same JVM, so that may be a better way to go than being skimpy on memory per Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
