Performance Tuning with SQL Server Dynamic Management Views

Chapter 7: OS and Hardware Interaction
switches, indicating that many SQL Server tasks are giving up control before completing,
is not ideal as it increases load on the CPU simply to allow more users to feel as if they are
being served.
With the values from the query in Listing 7.19 we can get the counts of the various
operations related to context switching that have occurred since the last reboot.
SELECT scheduler_id ,
preemptive_switches_count ,
context_switches_count ,
idle_switches_count ,
failed_to_create_worker
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255
Listing 7.19: Investigating context switching.
One-off queries of this sort, using the "History" columns, are not necessarily very useful.
A large number of context switches, accumulated over a long period, may simply reflect
the activity of scheduled nightly processes, where such context switching does not affect
the users. In order to detect excessive context switching during normal OLTP operations
caused, for example, by abnormally high user loads, we need to take a baseline measurement
and then track and compare the results over time.
As noted during the earlier discussion on common wait types, hyper-threading
(parallel execution) in OTLP systems can lead to context switching, and to CXPACKET
and SOS_SCHEDULER_YIELD waits. Furthermore, certain hyper-threading
implementations in older processors do not "play nicely" with the SQL Server engine
and can exacerbate the issue. According to Zach Nichter, in his Technet Magazine
article, Optimizing SQL Server CPU performance, at http://technet.microsoft.com/
en-us/magazine/2007.10.sqlcpu.aspx, if hyper-threading is enabled and you are seeing
more than 5000 * (Number of Processors) context switches per second, it suggests that
the scheduler is context switching between the same processor, yet thinking it is
swapping to a different one, and you should consider turning hyper-threading off and
298