Caldarale, Charles R wrote:
[...]
Thanks for the many comments.
After this processing, the process in a "top" display shows
the following :
22175 star 21 0 266m 23m 11m S 1.0 4.6 0:14.61 java
(where 266m is the virtual memory, and 11m the resident one).
The top virtual number is just what's in the memory map for the process, so
that includes files, code, non-Java stuff, etc., as well as the JVM heap. The
resident memory number is the pages that happen to be in RAM at the moment.
Compared to the numbers I see in the jconsole VM summary below,
these memory figures seem to show a gross disproportion, or am I
interpreting this wrong ?
What I meant above was the apparent disproportion between the "266M"
number and what (I think) I see really used by the application according
to jconsole.
But from you comment above, I gather that I was wrongly fixated on that
number (266M) and that it does not really represent any real memory used
in any permanent way by the process. What really matters is the
"Resident" part of it (23M), as compared to how much physical RAM the
system really has, right ?
Snapshot 1
Current heap size:
785 kbytes
This is just the combined virtual size of the new and old generations; it does
not include PermGen.
Maximum heap size:
65.088 kbytes
How big the new + old can get, if needed.
And can be controlled by the -Xmx<size> switch, yes ?
Committed memory:
1.984 kbytes
Includes the JIT's code pool, C heap, Java heap, PermGen, and various other
bits and pieces the JVM knows about.
Committed virtual memory:
270.980 kbytes
Total physical memory:
516.920 kbytes
Free physical memory:
6.852 kbytes
Total swap space:
1.297.564 kbytes
Free swap space:
1.234.376 kbytes
All of the above are for the entire system, not just this one process.
Understood.
Snapshot 2
Current heap size:
1.828 kbytes
The heap has expanded a bit.
Maximum heap size:
65.088 kbytes
This can't change.
Committed memory:
2.452 kbytes
Increased due to heap expansion plus probable enlarging of the code pool, C
heap, PermGen, etc.
Nothing unexpected here.
Ok.
Now a final question on this app :
By running the requests that lead to the snapshot 2 above, I believe I
have pretty much "stressed" that app as much as I can (they were
relatively "heavy" requests, involving a fair amount of XML parsing).
After watching jconsole for a while, I noted that the total heap space
used always remained below 8 Mb, and the non-heap space remained below 9
Mb at all times. So, I have incrementally brought down the value of some
switches, to this level :
-server -Xms16M -Xmx32M -Xmaxjitcodesize16M
without apparently having any effect on the application's ability to
process requests. My idea in doing this was to reduce the amount of
system memory this application maybe reserves for no benefit, and thus
leave more real RAM for others.
Considering the numbers above, in your opinion is there anything I
could/should still try, while still leaving a margin for the application
to support maybe a higher level of requests ?
I am not looking for definite answers here, just trying to get a feel
for the stuff, what is important or not.
Like for instance if you told me to never touch this -Xmaxjitcodesize,
that it doesn't bring anything and could crash the application and cause
all my hair to fall off, or anything along those lines.
The point is, after that I'm going to go through the same kind of
exercise with Tomcat, and I want a feel for what I should or should not
play with.
Thanks
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
