> > Get lots & LOTS of RAM (512MB minimum I would say)
> >
> > I use RH6.2 - I think 7 is a bit buggy for server use.
> > I find IBM's JDK 1.3 a bit more robust than Sun's but I'm not sure
> > there's a lot in it.
>
> IBM's JVM currently has *SERIOUS SMP ISSUES* under Linux. It is not
> yet ready for use in a production environment. Though it is faster
> than Hotspot (yes, we did some benchmarking to test this), it is not
> robust enough to use under anything other than light load. IBM is
> aware of the issues, and is already working to address them.
>
> Sean is also dead-on with his comments on memory. Don't forget to
> configure the JVM to make use of this memory as well. :)
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
=======================================================
> +1 on Linux as your Java server platform.
Righto!
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
