|
> ipvsadm -L -n --stats
> ipvsadm -L -n --rate
The --stats switch gives totals for packets in/out.
The --rate switch shows pps, but the man page does not say what the
averaging period is. I'll try it during a busy production day and see
what I get.
> Just as a test, what happens if you move the checkinterval out
> to (say) 5, 10, 20 or 30 seconds?
I changed it to 5 seconds, but no significant change was apparent. Then
I changed it to 10 seconds and there was a definite, observable drop in
CPU utilization. A graph of the past 6 hours shows that usage has now
flattened out and is now averaging less than 10%.
> Can you tolerate that level of pause if something happens to a
realserver?
I don't know. These are medical applications, and doctors are often
grumpy about transient glitches in their applications while trying to
document patient encounters. I'm thinking something like this might
possibly work for the short term:
checkinterval=10
checktimeout=5
negotiatetimeout=8
checkcount=1
But it would still be a temporary solution and this raises a general
question about load-balancer scaling. Right now I have 120 VS, but in a
year or two it will be 240. In 4 years it could be 500+. I can't just
keep increasing the checkinterval. Ultimately, I'm going to have to try
multiple instances of ldirectord.
Which raises a question about LVS. Could it get confused with multiple
ldirectord instances constantly forking ipvsadm?
Disclaimer - November 1, 2008
This email and any files transmitted with it are confidential and intended
solely for LinuxVirtualServer.org users mailing list.. If you are not the named
addressee you should not disseminate, distribute, copy or alter this email. Any
views or opinions presented in this email are solely those of the author and
might not represent those of . Warning: Although has taken reasonable
precautions to ensure no viruses are present in this email, the company cannot
accept responsibility for any loss or damage arising from the use of this email
or attachments.
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/
|
