|
Hello,
On Fri, 4 Nov 2005, Horms wrote:
> I notices that if persistance timeout is less than 2 min
> (the FIN_WAIT timeout) then it will expire before its
> controlled connections. This causes ip_vs_conn_expire to
> set the template's timeout to 2min. Which caues somewhat unexpected
> results if the persistance timeout, like say 10s.
>
> The patch below is a completely untested first cut at fix,
> it tries to resolve the problem by invalidating expired
> templates. So while they will stick around in the table for
> a bit longer, they won't take effect any more.
This patch looks ok but may be it is better this
timeout restriction to be controlled with sysctl var. This
new behaviour is dangerous for sessions that include many
connections from same client. You broke the affinity without
considering the other connections, may be the user wants all
connections to go to same RS, even if the cost is extended
template lifetime.
What is strange to me is that timeout of 10 seconds is
used for TCP connections. What kind of setups use such low value?
So, there can be a sysctl var "extra_persistence",
"persistence_extent" or another more suitable name. Its default
value can be "60" seconds, as now. The dangerous value of 0 will
invalidate the template as you propose (but still use some timeout
to check for removal). Any other value will be used as before in
ip_vs_conn_expire, just for templates.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
