Steven Wort

Steven Wort

Steven Wort

Steven Wort has been working with SQL Server since the early days of SQL Server way back in 1992-93. He is currently a developer in the Windows Division at Microsoft, where he works on performance and scalability issues on large database systems for the Windows Telemetry team. Steven has been at Microsoft since 2000. Prior to working in the Windows Division, Steven spent 2 years working in the SQL Server group, working on performance and scalability. Steven’s first 3 years at Microsoft were spent working in support as an escalation engineer on the SIE team. During this time, Steven was able to travel the world working with some of Microsoft’s customers on their performance and scalability issues.

Before coming to Microsoft, Steven spent 20 years working in the United Kingdom as a freelance consultant, specializing in database application development. When Steven isn’t busy working, he can be found spending time with his family and enjoying many fitness activities in the outdoors of the Pacific Northwest. Steven authored chapter 5.

His other books include:

5 thoughts on “Steven Wort

  1. On the bottom of page 141 the statement “Each successive layer is physically farther from the processor core, and larger and slower relative to main memory.” Does not make sense to me, perhaps I don’t know what “main memory” is. I would have expected this statement to be something like
    Each successive layer is physically farther from the processor core, and larger and slower relative to each other with main memory being the largest and slowest at the end of the chain.

  2. Hi, Tom. This sentence refers to the layers of cache. L1 cache is the closest to the CPU, and it’s extremely fast, but there’s not much of it. L2 cache is one layer farther away from the CPU, and is still pretty fast – but not as fast as L1 – and there’s more of it. All of this cache is faster than main memory.

    Ars Technica has a pretty good article explaining CPU cache:

    http://arstechnica.com/old/content/2002/07/caching.ars

    Hope that helps!

  3. Hi Steven,

    On pages 140-141 where you talk about the use of hyperthreading and the fact that you may not see any improvement for OLTP workloads (or in fact a degradation). I would like to test my system but ideally don’t want to reboot my server and change the BIOS setting. I was wondering about just setting the affinity mask so that each even CPU core was deactivated (my server is dedicated to SQL and has only one instance). Would you agree that this would have the same net effect as disabling hyperthreading? It would have the advantage of not emptying my plan cache/buffer pools as well as obviously not causing any downtime.

    Cheers,
    Ben

  4. Ben – no, unfortunately, that doesn’t give you the same effect. Remember that the OS, drivers, and background tasks will still be running and unaffected by the affinity mask. They’ll still be submitting work to the CPUs.

  5. Thanks for the quick response Brent – and that makes sense. I suppose I just thought that since the main cause of concern with hyperthreading for SQL seems to be parallelization of queries onto ‘fake’ cores leading to contention between the HT pair (if they are both chosen to handle threads for the same query), that at least you could see if your queries sped up by taking them out of the affinity mask.