|
On Fri, 6 May 2005, Julian Anastasov wrote:
>
> Hello,
>
> On Sun, 1 May 2005 markdv.lvsuser@xxxxxxxxxx wrote:
>
> > > It looks like enties in connection tracking table are never removed.
> > >
> > > In an attempt to limit the no of entries I issue an 'ipvsadm --set 0 0 10'
> > > expecting to see the entries expired (and removed from the table) in 10
> > > seconds. But after more than an hour the backup director (having been
> > > activ only a short time while the primary was rebooted) still has 696526
> > > entries in the table.
> > >
> > > This is a dual Xeon(TM) CPU 2.80GHz box and a 'cat ip_vs_conn | wc -l'
> > > takes 8 minutes!!
>
> It is SMP, what is the CONFIG_PREEMPT value?
Oeps I mixed up some boxes.. this one is single cpu... but it has HT and
it is an SMP kernel.
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT is not set
> > > Some things I don't understand:
> > >
> > > Although I do a 'ipvsadm --set 0 0 10' entries in /proc/net/ip_vs_conn
> > > still have larger timeout values (last column right?!)
> > >
> > > UDP C3F11870 0504 C3F14D36 0035 0A1F42B4 0035 UDP 59
> > >
> > > Then, when continuously 'grepping' for an entry I see that value decrease
> > > to 0... and then - to my suprise - it just jumps back to 59 instead of
> > > disapearing...
>
> It looks like ip_vs_conn_expire detects unexpected cp->refcnt
> or cp->n_control (not likely). So, only on higher load UDP conns are
> not freed, are you sure that TCP conns are freed? I assume it is
AFAICT yes.. There are also a few persisten TCP services on the box so
there are some templates still there.. I'd have to wait a couple of hours
to make sure they are also cleaned up... but so far this looks good.
> not easy to set /proc/sys/net/ipv4/vs/debug_level to 20 for 2-3
> seconds to catch in logs some debug messages?
Don't have that file so I suppose I would need to re-compile with debug
support?! What would that do for performance at my rates (>2000 InPPS)?
This is a production server so...
If performance won't suffer too much I'd be willing to give it a go.
Rgds,
Mark.
|
