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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
