|
> I finally got around to preparing the backport and patch for Dave,
> and in the course of doing this I realises that as long as
> ip_vs_conn_expire() doesn't reeset the timer, the problem goes away.
> This is because the problem is not how long the persistance entry
> stays around, but rather that it changes from the user-configured
> value.
Seems so, yes. Why was it done in the first place?
> ip_vs_conn_expire_now() used to set timeout values to 0,
> and because of this ip_vs_conn_expire() reset them to some
> other value. However, ip_vs_conn_expire_now() now deletes
> timers, so there is no reason for ip_vs_conn_expire() to
> reset timers.
Ahhh ;)
> It turns out that the current behaviour causes the timeout of
> persistance templates to be changed from their user-configured
> timeout in the situation where they timeout before their controled
> connections. This can happen if the user configures the
> persistane timeout to less than IP_VS_TCP_S_FIN_WAIT (2 minutes).
> And although such small persistance timeouts are of questionable
> value, its still an unexpected, weird behaviour, without any
> benifits.
It's not so questionable if you run a site that should maintain 10k
sessions/s or so in persistency mode :). I got to see LVS use 1.6 GB of
RAM once.
> See:
> http://archive.linuxvirtualserver.org/html/lvs-users/2005-11/msg00096.html
>
> Signed Off By: Horms <horms@xxxxxxxxxxxx>
Maybe Signed-Off-By?
> diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
> index f828fa2..c0c9abb 100644
> --- a/net/ipv4/ipvs/ip_vs_conn.c
> +++ b/net/ipv4/ipvs/ip_vs_conn.c
> @@ -525,8 +525,6 @@ static void ip_vs_conn_expire(unsigned l
> {
> struct ip_vs_conn *cp = (struct ip_vs_conn *)data;
>
> - cp->timeout = 60*HZ;
> -
Obvious enough. I will test the 2.4 version of your patch next week.
Cheers,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
