I wanted to thank Jonathan Kehayias for providing me with a script to check what wait stats are affecting my server the most. Recently we replaced a server with a much more robust one and I checked the wait stats after about a week of typical usage. Seems disk bottleneck issues were eliminated, but I wanted some clarification on some different wait types that came up after the upgrade. This is the script:
select top 10 *
from sys.dm_os_wait_stats
where wait_type not in -- remove system waits
(
'KSOURCE_WAKEUP', 'SLEEP_BPOOL_FLUSH', 'BROKER_TASK_STOP',
'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER',
'LAZYWRITER_SLEEP', 'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER',
'CHECKPOINT_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'LAZYWRITER_SLEEP',
'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE',
'SLEEP_TASK', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT',
'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS',
'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH'
)
order by wait_time_ms desc
Here's what showed up, with my comments on what I think would cause them:
OLEDB -- our app uses a lot of COM, so I'm assuming this is expected
MSQL_DQ -- our app does not use distributed queries, but we have trans replication going. Does transactional replication cause this wait type to appear?
CXPACKET -- my guess is parallelism issues (now that we have 24 procs instead of 4), but I'm hesitant to pull the trigger on turning Max Degrees of Parrellism to 1 for the whole server
ASYNC_NETWORK_IO -- this was #4 on the list on our old server too. I am looking to see if our NICs are configured correctly, before moving on to see if we're simply querying too much data (if anyone has any ideas on how to go about fixing that, it would be very helpful!)
CMEMTHREAD -- we have 32 GB of memory installed on the box, max server memory set to 24 GB (so that OS, et al are happy). Reading up on this wait type points me to lots of ad-hoc queries bloating the proc cache with their execution plans that do not get re-used often. Checking sys.dm_exec_cached_plans confirmed this theory, showing about 50% of my proc cache is home to ad-hoc query plans.
LATCH_EX -- probably an app issue, not sure
WRITELOG -- I know why this happens, will fix later
BACKUPBUFFER -- backups
BACKUPIO -- backups
LCK_M_IX -- see LATCH_EX comment
Would I be spot on with some of these wait types? Are there other things I need to consider besides what I've indicated in my comments?
I look forward to reading your responses.