tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Monitoring Tomcat with Jconsole
Date Tue, 25 Nov 2008 00:01:51 GMT
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
>> 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.

>> 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,
> Nothing unexpected here.

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.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message