|
Hello,
On Fri, 6 May 2005, Mark de Vries wrote:
> OK. I checked again and all but 4 TCP enties have gone.
>
> But the 4 that are left puzzel me (again)
Yes, these TCP entries suffer from the same problem, it seems
TCP is more immune to this refcnt problem than UDP.
> lvs-dns1:~# ipvsadm -L -c -n | grep TCP
> TCP 00:54 NONE 101.232:0 77.43:80 10.31.66.163:80
> TCP 00:55 ESTABLISHED 101.232:1134 77.43:80 10.31.66.163:80
> TCP 00:47 ESTABLISHED 117.21:1255 77.43:80 10.31.66.162:80
> TCP 00:45 NONE 117.21:0 77.43:80 10.31.66.162:80
Above the two TCP ESTABLISHED entries for port 80 hold the
two persistent templates (TCP NONE) for their client IP.
> Why don't these transition state... I've watched these counters jump from
> 00:00 to 00:59 a couple of times now... Is that normal?
Not at all, there is a bug somewhere, it is evident, we
just don't know yet where it is.
> (This director is not active any more... No traffic for these IPs hits
> this box. verified using tcpdump.)
My first thought is that due to some locking problems the
cp->refcnt is in invalid state which only the debugging can prove.
There are two options, it is above or it is below the expected
value 1 during expiration.
If you compile with CONFIG_IP_VS_DEBUG it will not delay too
much the processing, only when you set the /proc value the things
can go catastrophic, so if you decide to try it i can recommend you
not to set it on boot but in some script that you can run at any time.
This script should do something like:
echo 20 > /proc/sys/net/ipv4/vs/debug_level
sleep 2
echo 0 > /proc/sys/net/ipv4/vs/debug_level
The goal should be we to catch in log messages like:
IP_VS_DBG(7, "delayed: refcnt-1=%d conn.n_control=%d\n",
atomic_read(&cp->refcnt)-1,
atomic_read(&cp->n_control));
If we see this for many entries we can try to understand
where the refcnt can be increased/decreased. You can use 8 instead
of 20 for this message.
BTW, do you have any /proc settings for IPVS? For example,
drop_entry, etc?
Another alternative is to try 2.6.12-rc3+ as it contains
some fixes.
> Rgds,
> Mark.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
