>Question, why would you need GC,heap or CPU stats from the Tomcat
>machine at all?
>in most cases, none of these stats can predict response times.
>The best way would be to simply record a history of response times, and
>then mod_jk can have algorithms (maybe even pluggable) on how to use
>thos
Question, why would you need GC,heap or CPU stats from the Tomcat
machine at all?
in most cases, none of these stats can predict response times.
The best way would be to simply record a history of response times, and
then mod_jk can have algorithms (maybe even pluggable) on how to use
those s
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 se
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 ma
Yefym Dmukh wrote:
You have oxymoron here. With session stickiness you are willingly
tear down the load balancer correctness because you don't wish/can
have session replication.
Generally you are right, but the ideal world is not the reality:
we use apache my faces implementation of jsf where t
op-the-world
GC managed by lb, as keep it simple approach ?
Mladen Turk <[EMAIL PROTECTED]>
05.07.2007 13:19
Please respond to
"Tomcat Developers List"
To
Tomcat Developers List
cc
Subject
Re: Feature request /Discussion: JK loadbalancer improvements for high
load
Yefym Dmukh wrote:
Actually the following was happening: the LB sends requests and gets the
session sticky, continuously sending the upcoming requests to the same
cluster node. At the certain period of time the JVM started the major
garbage collection (full gc) and spent, mentioned above, 20
Yefym Dmukh wrote:
Actually the following was happening: the LB sends requests and gets the
session sticky, continuously sending the upcoming requests to the same
cluster node. At the certain period of time the JVM started the major
garbage collection (full gc) and spent, mentioned above, 20
Hi Rainer,
seems we have still an issue in jvm config. we have not noticed the
concurrent mode gc failures that led to tomcat overload and bad responses.
14896.148: [Full GC 14896.148: [CMS (concurrent mode failure):
1102956K->326641K(2359296K), 4.0684463 secs] 1280549K->326641K(3067136K),
[CMS
Hi Rainer,
seems we have still an issue in jvm config. we have not noticed the
concurrent mode gc failures that led to tomcat overload and bad responses.
14896.148: [Full GC 14896.148: [CMS (concurrent mode failure):
1102956K->326641K(2359296K), 4.0684463 secs] 1280549K->326641K(3067136K),
[CMS
Well many beans are allready available :
java.lang.Theading
java.lang.MemoryPool
I could see also some beans related to CPU load but using a Sun JVM
(not on IBM).
2007/7/5, jean-frederic clere <[EMAIL PROTECTED]>:
Henri Gomez wrote:
> Something we should also check is the CPU load of the Tomca
Henri Gomez wrote:
Something we should also check is the CPU load of the Tomcat instance.
May be it will be usefull also to let users/admin add their own
counters in the load estimation.
If you want to add this to Tomcat remeber that stuff needs a JNI module
to collect information from the OS/
Something we should also check is the CPU load of the Tomcat instance.
May be it will be usefull also to let users/admin add their own
counters in the load estimation.
For example, if some admins considers we should base the
load-balancing on HTTP requests or SQL access, and they have these
count
Hi,
implementing a management communication between the lb and the backend
is on the roadmap for jk3. It is somehow unlikely, that this will help
in your situation, because when doing a GC the jvm will no longer
respond to the management channel. Traditional Mark Sweep Compact GC is
not disti
Hi all,
sorry for the stress but it seems that it is a time to come back to the
discussion related to the load balancing for JVM (Tomcat).
Prehistory:
Recently we made benchmark and smoke tests of our product at the sun high
tech centre in Langen (Germany).
As the webserver apache2.2.4 has b
15 matches
Mail list logo
