Ok, I stand corrected.
>Rather, GC time in a modern JVM depends almost entirely on the number
and size of live objects at
>the time of the collection.
So.. giving the JVM many 1000s of times the space taken by live objects
(even under very high load) is a waste.
Should I have said "Allocating a huge amount of memory to the JVM isn't
always useful."?
In my experience using UseConcMarkSweepGC (or whatever it is under 1.6)
and tuning the Eden heap size does make a big difference to a server
application (tomcat) under continuous high load.
However most of my experience is based on Java 1.4.12
We only recently moved to 1.6 for our app and I have yet to load test.
To Karthik:
>This Tomcat needs to be restarted started every 12+ hrs
VisualGC should help you see whats happening.
If your using the Tomcat database connection pooling it also possible to
see the number of Idle and Active connections in the connection pool.
Context ctx = new InitialContext();
BasicDataSource ds =
(BasicDataSource)ctx.lookup(strDataSource);
intIdleConnections=ds.getNumIdle();
intActiveConnections=ds.getNumActive();
Try displaying these on a status web page within the app along with the
number of active sessions.
Is the number of Active connections growing without bound.
On our app we can also dynamically shorten the inactive session timeout
(from 15 min to 5 mins).
Ie if session count > 800 then all inactive session timeout = 5 mins. We
have a Javascript Timeout counter counting down in every pages status
line to alert the user.
This helps free session data.
I also detect if a new page has been requested less than 250ms ago and
redirect them off the site.
(to stop people hit refresh rapidly as a Denial of server attack)
Michael Simmons
Technical Advisor/Programmer
Information Technology Services (ITS) (Office of Finance and Resources)
Telephone: 6488 4792
Fax: 6488 3861
MBDP: M463
Email: [EMAIL PROTECTED]
-----Original Message-----
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Thursday, 5 June 2008 10:27 AM
To: Tomcat Users List
Subject: RE: JMX Perform GC TOMCAT 5.5.23
> From: Michael Simmons [mailto:[EMAIL PROTECTED]
> Subject: RE: JMX Perform GC TOMCAT 5.5.23
>
> Allocating more memory to the JVM isn't always best.
> Although it means the GC runs less often it causes it to take longer
> to run. Ie large pauses.
Another myth that won't die. Although it was true in some pre-HotSpot
JVMs that GC time was proportional to heap size, that has not been the
case for some time. Rather, GC time in a modern JVM depends almost
entirely on the number and size of live objects at the time of the
collection.
Regardless, make sure the maximum heap plus all the other process space
(for all processes) and whatever the kernel needs doesn't exceed the RAM
on the system; swapping during a GC is something you don't want to see.
- 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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
