Paul B. Henson wrote:
On Tue, 13 Apr 2010, Darren Reed wrote:
Also, try this with dtrace:
Ok, that hit a few times:
CPU ID FUNCTION:NAME
3 41493 fr_addstate:return num 136 max 72901
3 41493 fr_addstate:return num 167 max 72901
3 41493 fr_addstate:return num 219 max 72901
Do you still have insight into the actual code shipping in commercial
Solaris, or could it possibly have been munged by Sun engineers by now into
something completely different than your original code? Perhaps this is a
bug they introduced, regressions in ipf patches seem a pretty common
occurance <sigh>...
So there's one other issue that it could be and that is if
there are too many entries in the same hash bucket.
Unfortunately, the code you're running is too old to tell
me if that's the problem or not.
Try this out for size:
# ipfstat -slvdR | awk '/bkt/{print $11;}' - | sort -n | uniq -c | sort -n
. you should end up with a list of hash bucket numbers
sorted by the most populated ones.
Darren
