|
On Mon, 9 May 2005, Julian Anastasov wrote:
>
> Hello,
>
> On Sun, 8 May 2005, Mark de Vries wrote:
>
> > Ran ~8 seconds in debug_level 8:
> >
> > /var/log# grep delayed kern.log | cut -d':' -f 4- | sort | uniq -c
> > 272 IPVS: delayed: refcnt-1=-1 conn.n_control=0
> > 1 IPVS: delayed: refcnt-1=-12 conn.n_control=0
> > 104 IPVS: delayed: refcnt-1=-2 conn.n_control=0
> > 26 IPVS: delayed: refcnt-1=-3 conn.n_control=0
> > 8 IPVS: delayed: refcnt-1=-4 conn.n_control=0
> > 1 IPVS: delayed: refcnt-1=-5 conn.n_control=0
> > 1 IPVS: delayed: refcnt-1=-6 conn.n_control=0
> > 1 IPVS: delayed: refcnt-1=-8 conn.n_control=0
> > 3184 IPVS: delayed: refcnt-1=0 conn.n_control=0
> >
> > Well, that's interresting no?!
>
> Yes, thank you!
>
> > So... what's next? I sit back and relax while you go bug hunting?? :)
> >
> > Seriously, I looked over the code hoping I would find the missing inc or
> > whatever... but I'm afraid this is out of my league. But if there is
> > anything else you want me to try or do just let me know.
>
> You can try the attached patch. It removes one extra
> __ip_vs_conn_put from ip_vs_icmp_xmit. If it fixes the problem, it
> means you receive lots of incoming ICMPs from clients. May be
> FRAG_NEEDED messages?
approx ~50 incomming ICMP packets per second. 95% of which are port
unreachables. How does 50 compare to your definition of "lots"?
(frag_needed is unlikely as most dns packets are < 512 octets. I think
it's just bad firewalls on the client side... someting I'll look into.)
But anyway; I applied your patch to 2.6.11.8 and so far it looks
promesing! Although the trend is still a rising ip_vs_conn slab usage I
can sometimes see it go down. (Usage is still rising this time of day so
that upward trend seems normal.) Also I no longer see the 'delayed'
messages when settting the debuglevel to 8. So, looks like entries are
beeing expired! :). I'll keep a close watch and let you know how it
behaves @ and after peak hours.
Thnx & Regards,
Mark.
|
