|
Christopher Seawood wrote:
> On Tue, 8 Jun 1999, Wensong Zhang wrote:
>
> > Please tell me more about your VS running ipvs-0.4, so that I can
> > repeat the problem.
> >
> > The insanely huge timeout problem of masquerading entry like the
> > incorrect refcnt (Reference Counter) of the masquerading entry.
>
> We're using a standard masq setup with the real servers on a private
> network behind the VS. On the VS, we run:
>
> ipchains -F
> ipchains -A forward -j MASQ -s 10.0.1.0/24 -d 0/0
> ipchains -M -S 5 5 5
>
The timeout is in seconds. If you set the timeout of TCP, TCPFIN
and UDP to 5 seconds, 5 seconds and 5 seconds, I think they are
too short. Under realistic Internet load, most Internet connections
last longer than 5 seconds. Please try to set them to 5min, 1min
and 5min respectively, such as
ipchains -M -S 300 60 300
Then check whether the entry of huge timeout still exists.
I repeated your configuration, but didn't get the entry of huge
timeout. Since I tested it in the local network, all network
connections can be finished in 5 seconds, this might be the
reason I didn't get the entry of huge timeout. Anyway, I will
still try to reproduce the entry of huge timeout.
>
> ipvsadm -C
> ipvsadm -A -t ${vsaddr}:${port} -s wlc
>
> We have mon setup to add/remove the real servers as necessary using:
> ipvsadm $cmd -t ${vsaddr}:${port} -r ${addr}:${port} $wstr
>
> Btw, ipvsadm-1.0.0 does not seem to accept any args to -w except -1.
>
Sorry that I tried to make ipvsadm to accept zero weight (means server
is not available) but changed mind and left this bug in the problem. It was
fixed several days ago.
>
> > I have met the other phenonmena.
>
> We were running 2.2.7+0.2 on our primary servers but they were getting
> to the point where they required a reboot daily. We've been running
> 2.2.7+0.4 on our secondary server for about 2 days and one of our
> primaries for about a day. Both boxes show the huge timeout problem but
> neither seems to have the gradual slowdown problem.
>
> Here's another interesting artifact I came across:
>
> Homer (2.2.7+0.2) just before I rebooted it yesterday with about 6.5 hrs
> uptime:
> Module Size Used by
> ip_vs_rr 992 69 (autoclean)
> ip_vs_wlc 10242982 (autoclean)
> 3c59x 19112 2 (autoclean)
>
That's the incorrect usage of MOD_IN_USE_INC and MOD_IN_USE_DEC
in the VS patch v0.2 for kernel 2.2.
>
> Homer (2.2.7+0.4) now with about 29 hrs uptime:
> Module Size Used by
> ip_vs_rr 752 4 (autoclean)
> ip_vs_wlc 848 1 (autoclean)
> 3c59x 19112 2 (autoclean)
>
> - cls
>
Thank you,
Wensong
|
