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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
