tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Feature request /Discussion: JK loadbalancer improvements for high load
Date Thu, 05 Jul 2007 14:38:38 GMT
OK, this culd make sense, i.e. heap nearly full on node1 failover to 
other cluster member node2 (replcation assumed) and trigger GC by 
System.gc() on node1. Interesting idea ... (for JK3 and beyond).

Yefym Dmukh wrote:
> Mladen wrote:
>> This won't help much. The sticky session requests must be served
>> by the same node (group of nodes if using domain clustering),
>> and your requests will still be delayed by the JVM instance GC cycle
>> (It has to happen sometime, and you cannot depend on request
>> void intervals)
> 
> The main point was to use the stop-the-world collectors PROACTIVELY 
> managed by lb in order to:
>         eliminate the memory and cpu usage overhead ConcurrentXXX 
> ParallelXXX (i.e. up to 50% for mem ) collectors..
>         prevent the overloading of the single node that falls in GC-cycle. 
>  
>         reduce the complexity of jvm tunning
> 
> With an algorithm:
>         heap is almost full -> do not send the requests to the node 
> anymore and load the other nodes (wait some time        to give the chance 
> for the current workers to do the jobs), advise stop-the-world. Heap free? 
> Resume the load.
> 
> 
> Certainly this makes sense (if any) only for the setups with many small 
> jvms that have small CPU (or limited for the current needs) and huge Mem 
> size for the stateless applications or the applications with the short 
> session lifecycle.
> 
> Also may be it would make sense for the domained installations, in GC 
> cycles the other domain members will takeover the jobs. 
> all this makes sense only in case if the load balancer manages not only 
> the load but also GC cycles: kind of ideal JVMs level load-balancer for 
> the high load.
> 
> Regards,
> Y.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message