cvs commit: src/sys/netinet in_pcb.c tcp_subr.c tcp_timer.c tcp_var.h

[Mike Silbersack]

On Wed, 6 Sep 2006, Gleb Smirnoff wrote:

> Then we found the CPU hog in the in_pcblookup_local(). I've added
> counters and gathered stats via ktr(4). When a lag occured, the
> following data was gathered:
>
> 112350 return 0x0, iterations 0, expired 0
> 112349 return 0xc5154888, iterations 19998, expired 745

Ah, I think I see what's happening.  It's probably spinning because the 
heuristic isn't triggering on each entry, that doesn't surprise me.  What 
does surprise me is that it's expiring more than one entry - my original 
intent with that code was for it to free just one entry, which it would 
then use... meaning that I goofed up the implementation.

I had been thinking of rewriting that heuristic anyway, I'm sure that I 
can go back and find something far more efficient if you give me a few 
days.  (Or a week.)

> 1.78 hasn't yet been merged to RELENG_6, and we faced the problem on
> RELENG_6 boxes where the periodic merging cycle is present. So the
> problem is not in 1.78 of tcp_timer.c. We have a lot of tcptw entries
> because we have a very big connection rate, not because they are
> leaked or not purged.

Ok, just checking.

With this code removed, are you not seeing the web frontends delaying new 
connections when they can't find a free port to use?

Mike "Silby" Silbersack