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

[Ruslan Ermilov]

On Wed, Sep 06, 2006 at 09:49:15AM -0500, Mike Silbersack wrote:
> 
> 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.
> 
"it would then use"?  What do you mean?

> 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.)
> 
I don't see much point in doing it here.  TCP's slow timeout routing
does its job pretty well.  Besides, doing it here is IMO a layering
violation.

> >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?
> 
The TCP's slow timeout routine that runs twice a second takes care
of garbage collecting expired time-wait entries.  When we (just for
the sake of experiment) disabled the slowtimo code that removes the
expired entries, it would still work normally -- the tcptw zone would
be full (or with at most one entry free), and reusing one LRU entry
each time it's needed.  There wasn't any noticeable delay in
processing (in our case anyway).


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060906/555cb39d/attachment.pgp