For sure! We've been fighting with GC for a while now even with
incremental GC on, Hotspot eventually fills its heap. When that
happens, Hotspot switches over to non-incremental GC, and GC's large
amounts of memory at a time (which of course takes large amounts of
time!). From the user's perspective, the appliction can be
non-repsonsive for extended periods. This makes using it no fun.
Gonzalo, thanks for the great forward.
"Diethelm Guallar, Gonzalo" <[EMAIL PROTECTED]> writes:
> These comments posted to the Resin mailing list may be of interest:
>
> == Start of Inclusion
> =====================================================
> Alan Berezin wrote:
>
> > We found the problem with the spurious pauses and it has nothing to do
> with
> > Resin. It is the GC. Here is the background:
> >
> > Dell dual PIII server with 1GB mem. Running NT4, Resin 1.1.3, Sun VM 1.3a
> > with -Xincgc -Xms1024m
> >
> > This is a bad setup because the main memory is so large that when the GC
> > actually runs, if has to pick thru tons of stuff to clean up. This
> results
> > in 70-700 sec pauses a few times/day. There may be an added problem
> wherein
> > the heap can extend into NT virtual memory making GC even harder. We have
> > load tested on another server with similar config and can crash it under
> > heavy load.
>
> This is exactly the sort of situation where using "vertical" load-balancing,
> ie
> several independent Resin instances running in their own JVMs on the same
> machine is a smart move (and this applies to every other Servlet engine and
> other distributable, load-balanced Java application out there).
>
> Keep the memory size of each instance relatively low (128MB is fine for most
> web applications, keep it to below 256MB unless you have a very good reason
> to
> do otherwise) and set up as many instances as you need to fully utilize the
> available memory.
>
> This way when the GC runs in any of the instances, it will not stop that
> instance for as long a period, and the other instances still keep running
> (unless all of them GC at the same time, which would be a case of a very
> strange lock-step processing issue), so your application will remain
> responsive
> for most users, and the ones bound to the GC'ing instance will not suffer as
> long.
>
> Another note on load-balancing - when you do this in addition to
> fault-tolerant
> balancing (multiple machines each running multiple VMs), stack the instances
> in
> the <tcp-store/> ring in an alternating fashion, so that the backup instance
> for any session (which is always the next instance in the ring, right,
> Scott?)
> is on another machine. This will protect you from not just a VM crash but a
> system crash as well (with the added cost of more network traffic, but not
> more
> than if you were running just one VM per machine).
>
> --
> | | || ||| || | r a z o r f i s h , helsinki
> tel +358-9-4158 0823
> osma ahvenlampi fax +358-9-4158 0801
> [ technical director ] http://www.razorfish.fi
> == End of Inclusion
> =======================================================
--
Daniel Rall <[EMAIL PROTECTED]>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
