On 20.6.2010 14:06, Mark Thomas wrote:
On 20/06/2010 00:30, André Warnier wrote:
Just a note here : 160 X 512 MB = 81 GB.
If each Tomcat's JVM is allowed to use up to 512 MB of Heap, there might
be moments where a lot of JVM's will be using close to that amount.
Unless your system can really support that amount of real RAM, you may
be in for massive swapping.
And that could be a major problem. JVMs and swapping do not place nicely
together. To quote some folks at work that have been looking at this
recently performance "falls of a cliff".
Yep, I've seen that as well -- and the effect really is easy to
understand, esp. in the light of how Chuck explained the
mark-sweep-compact memory management.
The live objects are somewhat scattered throughout the heap, and
walking through the live object graph will touch all of them -- thus
if any was paged out at the moment, it will be paged in (most likely
forcing some other page out). If majority of the OS-level virtual
memory consumption consists of JVM heaps, then it's very likely that
the paged-out memory page does contain a live Java object - which will
again be paged in when the owning JVM does its "mark" phase.
Paging is suitable OS-level memory management for processes with full
pages of data that only needs to be accessed infrequently (or perhaps
only in the initialization phase of the application). Then these
seldom-accessed pages can be moved out to disk, freeing RAM for more
frequently needed items. With JVM memory management, everything is
accessed every now and then, making paging a real performance-killer.
--
..Juha
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
