To Hyper-Thread or not, that is the question….

September 15, 2010 jeffstokes2014 Uncategorized 5

So there was some discussion on an internal alias recently, like, well, this morning at 6 A.M….anyway, where we were talking about if having HT enabled was good or bad.  Some of our performance aliases tend to equate a HT processor as 20-30% of a normal processor.  It does give some benefit, but it also can cause some performance degradation.  This is counter-intuitive to the average bear until you start looking at the impact to L1/L2/L3 cache hits with and without HT processors.  Also, some code is optimized for a certain number of processors and adding additional processors is basically a waste of money….

For example, review the chart on recommended CPU configurations for Exchange Server 2010, found here:  http://technet.microsoft.com/en-us/library/dd346699.aspx

Anyway, there is no central list of products and their HT recommendations that I am aware of, so I’m making one right now:

Exchange Server 2010:  Do not HT your processors

“Hyperthreading causes capacity planning and monitoring challenges, and as a result, the expected gain in CPU overhead is likely not justified. Hyperthreading should be disabled by default for production Exchange servers and only enabled if absolutely necessary as a temporary measure to increase CPU capacity until additional hardware can be obtained.”

BizTalk 2004/2006/2006 R2:  Do not HT your processors

“It is critical that hyperthreading be turned off for BizTalk Servers. This is a BIOS setting, usually found in the Processor section of the BIOS setup. Hyperthreading makes the server appear to have more processors/processor cores than it actually does; hyperthread processors typically provide between 20 and 30% of the performance of a physical processor/processor core. BizTalk Server counts the (apparent) number of processors and adjusts its self-tuning algorithms accordingly; the “false” processors cause these adjustments to be skewed and are actually detrimental to performance.”

SQL 2005:  It depends

“The experiment confirms the theory. So does it mean you have to disable HT when using SQL Server? The answer is it really depends on the load and hardware you are using.

You have to test your application with HT on and off under heavy loads to understand HT’s implications.

Keep in mind that not only lazywriter thread can cause slowdown but any thread that performs large memory scan – for example a worker thread that scans large amount of data might be a culprit as well.

For some customer applications when disabling HT we saw 10% increase in performance. So make sure that you do your home work before you decide to hyper on not to hyper :-)”

 

More to follow….

5 Comments

  1. Jeff,

    Thanks for your post.

    The challenge with HT recommendations is that most are based on HT results from older Intel Pentium chips (NetBurst architecture?), and few are based on revised info from newer Intel chips and a comparison of old versus new HT.  I agree that HT results on older chips are not good, and HT should be disabled in those cases until proven to be an advantage (and not a disadvantage).

    "Internet search wisdom" is unfortunately jaded on point-in-time cases that may apply at the time but be different later, or may not fully state the conditions on which it applied at the time (NetBurst versus Nehalem, since Nehalem wasn't out at that time).

    Recent results from newer Intel HT chips (Nehalem and later) show more favorable results with HT for DB and other workloads, and corresponding recommendations to use HT in those cases.

    To simplify discussions for those less technically inclined, I refer to the older Intel chips as "Bad HT" (as in "don't waste your time") and the newer Intel chips as "Good HT" (as in "well worth your time").

    Does this match any other feedback you are finding?

    BTW – good to talk with you at the TechStravaganza event in Atlanta recently.

    Scott R.

    Reply

Leave a Reply