Home > Blogs > SQL Server and HyperThreading

SQL Server and HyperThreading

By  Oct 24, 2007

Topics: Data

I've been seeing a lot of chatter about SQL Server and hyper-threading processors. The question usually comes up, does HT make things worse or better for SQL Server?

The answer is, of course, it depends. First, a word on hyper-threading. Hyper-threaded processors split calls up so that one processor looks like two. So far, so good, especially for SQL Server. However, just like in real life, nothing is ever free.

The way this magic works is by sharing the memory bus on the processors (L1 and L2 cache). Normally the processing needs outweigh the penalty you pay in the memory.

In SQL Server, however, memory operations matter. It all has to do with threads, the basic level (although you can also go finer) of work SQL Server does. SQL Server has multiple kinds of threads, such as client request threads, worker threads, , and system threads. These threads can compete for access to L1 and L2, so in these cases it hurts. If the particular load doesn't cause these threads to interfere, it improves performance. In other cases they cancel each other out, leaving the server at the same level of performance.

Oh, and one more thing about HT processors - Windows 2000 schedules them as real processors, but Windows 2003 schedules them as real/logical. That's important because Win2K could tie up a single physical processor, leaving the other idle, but you won't get that behavior in Win2K3.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.