Hello Folks, This post is about troubleshooting CPU utilization of SQL Server hosting the ConfigMgr database. It talks about the general queries to find out the causes and talks specifically about parallelism.
To check which query is taking the Max CPU time run the following query
-----------------------------------------------------------
SELECT TOP 50
ObjectName = OBJECT_SCHEMA_NAME(qt.objectid,dbid) + '.' + OBJECT_NAME(qt.objectid, qt.dbid)
,TextData = qt.text
,DiskReads = qs.total_physical_reads -- The worst reads, disk reads
,MemoryReads = qs.total_logical_reads --Logical Reads are memory reads
,Executions = qs.execution_count
,TotalCPUTime = qs.total_worker_time
,AverageCPUTime = qs.total_worker_time/qs.execution_count
,DiskWaitAndCPUTime = qs.total_elapsed_time
,MemoryWrites = qs.max_logical_writes
,DateCached = qs.creation_time
,DatabaseName = DB_Name(qt.dbid)
,LastExecutionTime = qs.last_execution_time
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
ORDER BY qs.total_worker_time DESC
---------------------------------------------------------------
It’s also good to look at the tasks which are having the maximum wait time. You can do this by running the following:
select top 10 * from sys.dm_os_wait_stats order by wait_time_ms desc
In my case this returned a very high value for the wait_typeCXPACKET.
CXPACKET/Parallelism Explanation:
When a parallel operation is created for SQL Query, there are multiple threads for a single query. Each query deals with a different set of the data (or rows). Due to some reasons, one or more of the threads lag behind, creating the CXPACKET Wait Stat. There is an organizer/coordinator thread (thread 0), which takes waits for all the threads to complete and gathers result together to present on the client’s side. The organizer thread has to wait for the all the threads to finish before it can move ahead. The Wait by this organizer thread for slow threads to complete is called CXPACKET wait.
Note that not all the CXPACKET wait types are bad. You might experience a case when it totally makes sense. There might also be cases when this is unavoidable. If you remove this particular wait type for any query, then that query may run slower because the parallel operations are disabled for the query.
Parallelism: SQL Server provides parallel queries to optimize query execution and index operations for computers that have more than one microprocessor (CPU). Because SQL Server can perform a query or index operation in parallel by using several operating system threads, the operation can be completed quickly and efficiently.
For more info on parallelism: http://msdn.microsoft.com/en-us/library/ms178065(v=sql.105).aspx
When is Parallelism required?
We cannot discuss reducing the CXPACKET wait without talking about the server workload type.
OLTP: On Pure OLTP system, where the transactions are smaller and queries are not long but very quick usually, set the “Maximum Degree of Parallelism” to 1 (one). This way it makes sure that the query never goes for parallelism and does not incur more engine overhead.
EXEC sys.sp_configure N'max degree of parallelism', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
Data-warehousing / Reporting server: As queries will be running for long time, it is advised to set the “Maximum Degree of Parallelism” to 0 (zero). This way most of the queries will utilize the parallel processor, and long running queries get a boost in their performance due to multiple processors.
EXEC sys.sp_configure N'max degree of parallelism', N'0'
GO
RECONFIGURE WITH OVERRIDE
GO
ConfigMgr DB operations are normal OLTP queries so it’s good to go with less parallelism. In my case it had a value of zero which means the queries will utilize the available processors (in my case 16 core).
The moment we reduced the value to 1 we saw the drop in the performance and the CXPACKET was no longer the wait_type with the maximum wait.
Hope this helps !!
-Umair
Disclaimer:
This posting is provided "AS IS" with no warranties and confers no rights.