For anyone familiar with CICS, this works very much like Dynamic Storage
Area (DSA) compression. It can be very expensive (CPU time, storage
references which can cause paging, I/O to reload programs etc), so we
attempt to allocate enough storage to avoid it.
The ROT here seems to be to allocate enough heap for your normal
processing. Let gc do it's job at regular intervals (3-5 minutes, based
on what is tolerable), it should be short enough to have no impact on
normal use. It can be monitored through the verbose gc trace.
The less heap, the more gc will be called, which causes overhead. The
more heap, the less gc will be called, but it will run longer and the
app server may appear intermittently sluggish.
Adam Thornton wrote:
On Dec 9, 2005, at 11:38 AM, Mark Post wrote:
I'm not at all familiar with WAS internals. Is garbage collection
specific
to a particular session? If not, then your suggestion will affect
everyone,
not only the particular user that just got a response. It would
likely
generate a lot more garbage collection activity than otherwise.
--
Rich Smrcina
VM Assist, Inc.
Main: (262)392-2026
Cell: (414)491-6001
Ans Service: (360)715-2467
rich.smrcina at vmassist.com
Catch the WAVV! http://www.wavv.org
WAVV 2006 - Chattanooga, TN - April 7-11, 2006
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
