Abel MacAdam wrote:
So I take it we should reserve the 500 MB with fixed (or rigid I think it is
called) memory? That might cause other problems *). Thanks for the response.
*) When you reserve flexible memory the OS of the system VMWare runs on you
get a situation where more memory is allocated then flexible is available.
Compare it with airplane seets that often are oversold. By reserving rigid
memory I'm told the whole equation becomes far more complex.
Let's take the problem one bit at a time.
First, a JVM /is/ a virtual machine. It starts up as an application
inside of an OS. It grabs a number of resources, among them memory.
With the "-Xms" parameter, you are telling the JVM how much memory it
should grab, initially, for the Java Heap. That's only one part of the
memory it needs, but let's concentrate on that for now.
The "-Xmx" parameter on the other hand, fixes a maximum limit for the
size it will allocate, over time, to the Heap. How much it will really
use depends on how much the Java applications, which run inside the JVM,
will eventually need (Tomcat is such an application).
If the "-Xms" parameter is not set, then the JVM, initially, grabs some
default memory quantity (from the OS).
If the initial size (-Xms) is not equal to the maximum size (-Xmx), then
the JVM will try, when it does not need some Heap memory anymore, to
reduce it (down to -Xms if it can). When it needs more again, it will
re-allocate it, never exceeding -Xmx.
If "-Xms" and "-Xmx" are equal, then the JVM does not have to
allocate/de-allocate/re-allocate heap space continuously, which saves time.
Second level : this JVM runs inside an OS.
When it needs more memory, it requests it from the OS. When it does not
need a chunk of memory anymore, it /might/ return it to the OS. I
suspect that whether it does or not is not guaranteed, and may depend on
the particular JVM and the particular OS it runs under.
But anyway, obtaining memory from the OS and releasing it, is also an
overhead; so the least you have to do it, the better for performance.
Third level : the OS.
I may be mistaken, but I do not know of any OS which is capable to run
with a variable (dynamic) amount of memory. The amount available is
usually set when the OS boots, and does not change after that.
It may partially consist of "virtual memory" on disk. But it is
generally accepted that once the OS starts to really have to swap often
between physical RAM and virtual RAM on disk, bad things happen.
Fourth level : this particular OS, happens to run inside a VMWare
virtual machine. So it sees the "hardware" it runs under, in function of
what VMWare has configured as resources for this VM.
I may again be mistaken, but I do not think that VMWare, and this OS,
are capable of letting this VM run with an amount of RAM that varies
dynamically from one moment to the other.
In other words, whenever VMWare lets this machine run, it has to
allocate the same fixed amount of RAM to it. It is possible, again,
that part of the RAM would be "virtual RAM" on disk; but for the same
reason as above, I suspect that this would be quite bad for performance.
In other words, if VMWare regularly has to "swap out" one virtual
machine, in order to "swap in" another one, I believe you are going to
be facing some serious performance problems.
I am not the ultimate VMWare expert (yet) (and this is not the right
forum for that either), but personally I would never configure a VMWare
server in such a way that the total RAM of the virtual machines really
running inside it, exceeds the real RAM available on the physical
machine (minus what the underlying OS and VMWare themselves need).
RAM is cheap.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
