Performance Tuning with SQL Server Dynamic Management Views

Chapter 7: OS and Hardware Interaction
On the Vista Pro laptop that I am using to write this book, this query returned the
following:
SocketCount physical_memory_mb sql_max_virtual_memory_mb
-------------- --------------------- -------------------------
1 3571 2047
buffer_pool_committed_mb /3GB switch
--------------------------- -----------
228 off
I have a single dual-core processor, hence one socket; the physical memory matched
the memory shown in task manager on the performance tab, and I do not have the
IncreaseUserVa turned on, so my virtual memory is limited to less than 2 GB.
Thankfully, 32-bit processors are on the way out these days, and we can stop worrying
about the limitations of 32-bit addressing.
Investigating CPU Usage
In terms of complexity, SQL Server is almost an operating system in its own right and its
resource utilization patterns are, likewise, pretty complex. When a request is submitted to
SQL Server, it is assigned to a worker thread. Each of these threads is assigned to a CPU
by what is known as the SQL Server OS scheduler. For each CPU, there is only one
scheduler available for use by SQL Server, to execute user code, and only one request
(SPID or session_id) per scheduler can be running at any time.
Threads waiting for CPU time will be placed in the runnable queue; the longer the queue,
the higher the CPU pressure (see Listing 7.5). Threads whose associated request is waiting
for a resource to become free, or that have to perform I/O, will be moved to the waiter
list. If there are simply no available worker threads, a process will be blocked until one
becomes available, and moved to the work queue.
292