tcphashsz tuning guidance

[Christopher Caldwell]

Much thanks to Rick Jones for the explanation of tcphashsz at
ftp://ftp.cup.hp.com/dist/networking/briefs/tcphashsz.txt


How about some advice on how/when to tune tcphashsz. What can we measure to help influence how we tune?

[harry d brown jr]

Well the first question is when doing tuning is: What am I trying to accomplish? If you want to reduce the number of concurrent tcp connections then you reduce this parameter.

from: http://us-support.external.hp.com/cki/bin/doc.pl/sid=a45b58cc03d9b694f2/screen=ckiDisplayDocument?docId=200000010745233

The size of the hash table for TCP connections is determined by the kernel parameter tcphashsz. This kernel parameter should only be modified under the direction of Hewlett-Packard.



live free or die
harry

[S.K. Chan]

ooo.. a very sensitive kernel parameter to mess with. Harry's right, don't mess with it until you get HP involve ..

[Christopher Caldwell]

Rick had some good info in this thread:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xe1b14e49c5cdd5118ff40090279cd0f9,00.html

I'm hoping he'll chime in here to finish the thread.

In a nutshell, I'm trying to improve the performance of my HP-UX boxen by understanding how tcphashsz works, when it should be modified, how to test/measure/evaluate tcphashsz tunes, etc. tcphashz seems relevent in my environment: web hosting.

Since
-tunes to tcphashsz are used to set the HP's SPECweb benchmark,
and
-HP uses that benchmark in sales literature,
and
-there's little or no external documentation on tcphashsz (save what Rick wrote yesterday)
and
-there's plenty of great information in the forums on tuning other knobs in HP-UX
and
-Rick seems to indicate that perhaps there's more fear of tcphashsz than warranted :"I'm surprised the wording is as strong as it is. Tpchashsz is something we've been tuning on most of our SPECweb9X submittals with HP-UX 11 for years and years now."

I thought folks might appreciate some info on tcphashsz.

[rick jones · Accepted solution]

well, keep in mind that in addition to being called the "network performance curmudgeon" i am also sometimes called a "loose cannon" :)

iirc, I didn't need to alter tcphashsz when i was doing my 20K simultaneous software downloads on an l3000 writeup (ftp://ftp.cup.hp.com/dist/networking/briefs/)

the "real" way to see if increasing tcphashsz is indicated is to take a kernel profile. however, that is indeed something only done under the auspices of HP folks.

barring that, the basic search methods coudl be employed - start with the default of 2048, take your baseline. then go to 4096, then 8192 etc.

the main benefit in SPECweb (96 at least) was because there were literally up to millions of TIME_WAITS being tracked in the box - the number of TIME_WAITS in a SPECweb96 benchmark was SPECweb96score*60. It is somewhat less for a SPECweb99 score since the metrics are rather different.

I would guess that unless you have more than say 5000 simultaneous connections, or are churning through connections at a rate of more than say 100 to 200 per second, you probably do not need to worry about tcphashsz