> From: André Warnier [mailto:[EMAIL PROTECTED] > Subject: Re: Monitoring Tomcat with Jconsole > > 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.
Correct; it's analagous to profit claimed by certain financial institutions... > What really matters is the "Resident" part of it (23M), as > compared to how much physical RAM the system really has Yes, but be wary of how big the Java heap can get. One normally runs server programs with -Xms == -Xmx, partly to avoid any chance of the heap growing and running into page thrashing. > > How big the new + old can get, if needed. > And can be controlled by the -Xmx<size> switch, yes ? Correct. > 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). Depends on whether or not the app is capable of processing multiple requests concurrently (like Tomcat and most servers can). > 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. It's useful to size the heap appropriately, balancing GC frequency against RAM usage. I wouldn't mess with the max code size attribute - let the JVM use what it needs; the rest won't get any pages allocated to it anyhow. > 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'm not really in a position to say - I have no real feel for what this particular app needs when the going gets tough. Best for you to continue to monitor it, preferably in a production environment if you can (as well as doing your own stress testing, of course). > Like for instance if you told me to never touch this > -Xmaxjitcodesize, that it doesn't bring anything and > could crash the application It probably provides no benefit, and could cause the app to run slowly if the JIT doesn't have enough room to store all the generated native code, causing recompilation of methods. It's not likely to cause a crash, but I suspect the main purpose of that option is to stress test the JIT. > and cause all my hair to fall off If it hasn't done so by now, that's probably not a concern. (I've still got mine.) > 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. The main thing to adjust is the max heap size. Fiddling with the other stuff will buy you a lot less than streamlining your webapp code. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
