4. Processor-Configuration Properties
You can use the processor-configuration properties (listed in Table 3) to control how SQL Server uses multiprocessor computers.
Table 3 Processor-Configuration Properties
The Processors tab (see Figure 3)
of the SQL Server Properties page determines how SQL Server uses
multiprocessor computers. Most of these options are moot in a
single-processor server.
Processor Affinity
In a multi-CPU server, the operating
system can move processes to CPUs as the load requires. The SQL Server
processor affinity, or the relationship between a task and a CPU, can
be configured on a per-CPU basis. By enabling the affinity between SQL
Server and a CPU, you make that CPU available to SQL Server, but it is
not dedicated to SQL Server. Therefore, although a CPU can't be forced
to run SQL Server, it can be segmented from SQL Server.
SQL Server supports processor affinity by means of two affinity mask configuration options: affinity mask (also referred to as CPU affinity mask) and affinity I/O mask. The affinity mask configuration option enables you to specify which CPUs on a multiprocessor computer are to be used to run threads from SQL Server. The affinity I/O mask
configuration option enables you to specify which CPUs are configured
to run SQL Server threads related to I/O operations. These two
configuration options give you the ability to allocate particular CPUs
for disk IO processing and particular CPUs for nondisk-related CPU
requirements.
The affinity mask is a bitmap in which the
rightmost bit specifies the lowest-order CPU(0), the next rightmost bit
specifies the next lowest-order CPU(1), and so on. A 1-byte (8 bits)
mask covers 8 CPUs in a multiprocessor server, a 2-byte mask covers up
to 16 CPUs, a 3-byte mask covers up to 24 CPUs, and a 4-byte mask
covers up to 32 CPUs. A 1 bit specifies that the corresponding CPU is
allocated and a 0 bit specifies that the corresponding CPU is not
allocated.
When you configure the affinity mask option, you
must use it with an affinity I/O mask. Enabling the same CPU for both
affinity mask and affinity I/O mask configuration options is not
recommended because doing so will cause contention on the CPU for both
resources. The bit corresponding to each CPU should be one of the
following:
- 0 for both affinity mask and affinity I/O mask options
- 1 for affinity mask and 0 for affinity I/O mask option
- 0 for affinity mask and 1 for affinity I/O mask option
As an example, say on a 8-CPU system, you want to
allocate CPUs 0, 1, 2, and 3 for processing SQL Server threads, CPUs 4
and 5 for disk I/O processing, and CPUs 6 and 7 for other non-SQL
Server activities. This means the last 4 bits will be one for the affinity mask bitmap (00001111) that is 15 in decimal and the fifth and sixth bits will be one for the affinity I/O mask (00110000) that is 48 in decimal.
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘affinity mask', 15;
RECONFIGURE;
EXEC sp_configure ‘affinity I/O mask', 48;
RECONFIGURE;
The affinity mask setting takes effect immediately without requiring a restart of the SQL Server service whereas the affinity I/O mask setting takes effect only after restarting the SQL Server service.
Note
The default value of 0 for the affinity mask
option indicates that all the processors on the server are available
for processing SQL Server threads. The default value of 0 for the affinity I/O mask option indicates that any CPUs that are eligible to process SQL Server threads are available for disk I/O processing.
Note
The affinity mask feature will be
removed in a future version of Microsoft SQL Server. It is advised that
you do not use this feature in new development work.
In Management Studio, processor affinity is
configured by means of the check boxes on the Server Properties
Processors tab (refer to Figure 3).
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure ‘affinity mask', 3;
RECONFIGURE;
Note
Affinity support for SQL Servers with 33
to 64 processors is available only on 64-bit SQL Servers and requires
the additional use of affinity64 mask and affinity64 I/O mask configuration options.
Max Worker Threads
SQL Server is a multithreaded
application, meaning that it can execute on multiple processors
concurrently for increased performance. Multithreaded applications also
enable more efficient use of a single processor because this enables
another task to execute while a task waits for a process that doesn't
use the CPU to finish. The threads are designed as follows:
- A thread for each network connection.
- A thread to handle database checkpoints.
- Multiple threads to handle user requests. When SQL Server handles a
small number of connections, a single thread is assigned to each
connection. However, as the number of connections grows, a pool of
threads handles the connections more efficiently.
Depending on the number of connections and the
percentage of time those connections are active (versus idle), making
the number of worker threads less than the number of connections can
force connection pooling, conserve memory, and improve performance.
In Management Studio, the max worker threads
option is set by typing or selecting a value in the Maximum worker
Threads box on the Server Properties Processor tab .
From code, the maximum number of worker threads is set by means of the sp_configure stored procedure and the max worker threads option. For example, the following code sets the max worker threads to 128.
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘max worker threads', 128;
RECONFIGURE;
SQL Server service must be restarted for the max worker threads setting to take effect.
Best Practice
On SQL Server 2008 and SQL Server 2012, the default value of 0 for the max worker threads
property provides the best performance of SQL Server. This default
value indicates that SQL Server automatically determines the correct
number of active worker threads based on user requests.
If you do need to change the default value, it is not recommend to set the max worker threads
option to a small value because that may prevent enough threads from
servicing incoming client requests in a timely manner and could lead to
“thread starvation.” However, do not set the max worker threads
option to a large value because that can waste memory because each
active thread consumes 512KB on 32-bit servers and up to 4MB on 64-bit
servers.
Tip
To view information about the connections established to this instance of SQL Server, query the sys.dm_exec_connections
dynamic management view. This information includes statistics about
each of the databases, connections by both local and remote users, and
details for each connection.
Priority Boost
Different processes in Windows operate at different priority levels, ranging from 0 to 31.
The highest priorities are executed first and are reserved for the
operating-system processes. Typically, Windows scheduling
priority-level settings for applications are 4 (low), 7 (normal), 13 (high), and 24 (real time). By default, SQL Server installs with a Windows scheduling priority level of 7. The default value of priority boost gives SQL Server enough CPU resources without adversely affecting other applications.
Best Practice
In almost all cases, it is recommended to leave the priority boost
option to the default value of 0. Raising the priority of SQL Server
may drain essential operating system and networking functions and
thereby result in a poorly performing SQL Server; in some cases it may
even result in a SQL Server shutdown. If you do change the priority
boost from 0 to 1, then be sure to test it thoroughly and evaluate all
other performance tuning opportunities first.
If you still insist on changing the priority boost configuration option, you can either use Management Studio or T-SQL-code. In Management Studio, priority boost is set to 1 by checking the Boost SQL Server priority check box in the Server Properties Processor tab .
Using T-SQL-code, the following command can set the priority boost option to 1. This sets the Windows scheduling priority level to 13 (high).
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘priority boost', 1;
RECONFIGURE;
SQL Server service must be restarted for the priority boost option to take effect.
Lightweight Pooling
You can use the lightweight pooling option for servers with multiprocessing servers to reduce the overhead of frequently switching processes among the CPUs.
Best Practice
For most SQL Servers the default value of 0 for the lightweight pooling
configuration option gives the best performance. In fact, changing the
value from 0 to 1 may result in decreased performance. If you do change
the lightweight pooling option to 1, then be sure to test it thoroughly and evaluate all other performance tuning opportunities first.
If you still insist on changing the value of the lightweight pooling option, you can either use Management Studio or T-SQL-code. In Management Studio, lightweight pooling can be set to 1 (default is 0) by checking the Use Windows fibers (lightweight pooling) check box on the Server Properties Processor tab .
In code, to set the lightweight pooling option:
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘lightweight pooling', 1;
RECONFIGURE;
SQL Server service must be restarted for the lightweight pooling option to take effect.
Caution
The need for the lightweight pooling option is reduced by improved context switching in Microsoft Windows Server 2003 and 2008.
The lightweight pooling and clr enabled configuration options are mutually exclusive. You can use one of the two options: lightweight pooling or clr enabled.
If you disable CLR, features that rely on it (such as hierarchy data
type, replication and Policy-Based Management) will not work properly.
Parallelism
On a multiprocessor server, SQL Server
detects the best number of processors that can be used to run a single
statement for each parallel plan. The max degree of parallelism configuration option can be used to limit the number of processors to use in a parallel plan execution.
SQL Server's query optimizer is a cost-based
optimizer, which means it chooses a plan that returns the results in a
reasonable amount of time with a reasonable resource cost. SQL Server
always considers a serial plan first. If this serial plan costs less
than the cost threshold for parallelism value, then no parallel plan is generated. The cost threshold for parallelism
option refers to the cost of the query in seconds on a specific
hardware configuration. If the cheapest serial plan costs more than the
cost threshold for parallelism, then a parallel plan is produced. The parallel plan cost is compared with the serial plan cost, and the cheaper one is chosen.
Complex queries benefit the most from parallelism
because generating a parallel query execution plan, synchronizing the
parallel query, and terminating the query all require additional
overhead. To determine whether a query uses parallelism, view the query
execution plan in Management Studio. A symbol shows the merger of
different parallel query execution threads.
Note
The default value of the max degree of parallelism option is 0, which tells SQL Server to use all the available processors.
In Management Studio, you can set the max degree of parallelism
option by entering the maximum number of processors to use in a
parallel plan in the Max Degree of Parallelism box on the Server
Properties Advanced tab.
The following code sets the max degree of parallelism option to 4.
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure ‘max degree of parallelism', 4;
RECONFIGURE;
Best Practice
The default value of 0 for the max degree of parallelism
option works well for SQL Servers that have up to 8 processors. The
performance of the SQL Server can actually degrade if more than 8
processors are used in a parallel plan. It is recommended to change the
max degree of parallelism option
on SQL Servers that have more than 8 processors from the default value
of 0 to 8 or less. For servers that have NUMA configured, the max degree of parallelism option should not exceed the number of CPUs that are assigned to each NUMA node.
For servers that have hyperthreading enabled, the max degree of parallelism option should not exceed the number of physical processors.
Although a parallel query execution
plan can be much faster, there is a point at which the parallel query
execution becomes inefficient and can even extend the execution time.
For example, parallel queries performing small joins and aggregations
on small data sets might be inefficient. Also, due to different degrees
of parallelism chosen at execution time, response times for one query
can be different depending on resource availability such as CPU and
memory.
Many people recommend setting the max degree of parallelism
option to 1 for OLTP workloads. This can be a misleading
over-generalization that folks who are not familiar with the topic
might blindly follow. Certain applications need the max degree of parallelism option set to 1. For example, the max degree of parallelism
option is set to 1 during the configuration of BizTalk Server for the
SQL Server instances that host the BizTalk Server MessageBox databases.
As per BizTalk's documentation, changing this to anything other than 1
can have a significant negative impact on the BizTalk Server stored
procedures and performance. With this in mind, it is recommended to
check with your application vendor for any best practices for the max degree of parallelism
option. If you cannot contact the vendor or it is an in-house built
application, you may want to test with different values of the max degree of parallelism option to see which value gives the maximum performance gains.
If you find that setting the max degree of parallelism
option to 1 or any low value works best for your workload, it is
recommended to change the option back to 0 (or 8 if you have more than
8 CPUs) when you perform database maintenance tasks such as index
creation, index rebuild, and checkdb because this can speed up these
tasks if they can leverage more CPUs. You can change the max degree of parallelism option without the need to restart SQL Server.
Although these server-tuning options
can affect performance, performance begins with the database schema,
queries, and indexes. No amount of server tuning can overcome poor
design and development.
A safer alternative than simply
enabling the max degree of parallelism setting at the instance level,
is to make use of the MAXDOP query hint. This, however, requires a deep
understanding of what the query needs and how it behaves. Query hints
should be used with caution and tested extensively.
You need to do extensive testing with
your workloads to find the configuration that works best for your
particular setup.
Note
The default value of the cost threshold for parallelism
option works well for most SQL Servers. Change the default value only
after performing thorough testing and considering other performance
tuning opportunities.
However, if you insist on changing the default value of the cost threshold for parallelism option, then you can either use Management Studio or T-SQL code. In Management Studio, the cost threshold for parallelism
option can be set by entering the desired value in the Cost Threshold
for Parallelism box on the Server Properties Advanced tab.
The following code sets the cost threshold for parallelism option to 30 seconds.
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘cost threshold for parallelism', 30;
RECONFIGURE;
