{"id":641,"date":"2010-12-09T15:18:00","date_gmt":"2010-12-09T15:18:00","guid":{"rendered":"\/blogs\/paul\/post\/Wait-statistics-or-please-tell-me-where-it-hurts.aspx"},"modified":"2026-03-21T19:04:30","modified_gmt":"2026-03-22T02:04:30","slug":"wait-statistics-or-please-tell-me-where-it-hurts","status":"publish","type":"post","link":"https:\/\/www.sqlskills.com\/blogs\/paul\/wait-statistics-or-please-tell-me-where-it-hurts\/","title":{"rendered":"SQL Server Wait Statistics (or please tell me where it hurts…)"},"content":{"rendered":"

(Check out my comprehensive library of all wait types and latch classes<\/a>.)<\/p>\n

[Last updated: March 21, 2026]<\/p>\n

How many times have you walked up to a SQL Server that has a performance problem and wondered where to start looking?<\/p>\n

One of the most under-utilized performance troubleshooting methodologies in the SQL Server world\u00a0is one called “waits and queues” (also known as “SQL Server wait statistics” or simply “wait stats”). The basic premise is that SQL Server is permanently tracking why execution threads have to wait. You can ask SQL Server for this information and then use the results to narrow down where to start digging to unearth the cause of performance issues. The “waits” are what SQL Server tracks. The “queues” are the resources that the threads are waiting for. There are a myriad of waits in the system and they all indicate different resources being waited for. For example, a PAGEIOLATCH_EX<\/a><\/em> wait\u00a0means a thread is waiting for a data page to be read into the buffer pool from disk. An\u00a0LCK_M_X<\/a><\/em> wait means a thread is waiting to be granted an exclusive lock on something.<\/p>\n

The great thing about all of this is the SQL Server *knows* where the performance issues are, and you just need to ask it…. and then interpret what it tells you, which can be a little tricky.<\/p>\n

Now – where people sometimes get hung up is trying to track down every last wait and figure out what’s causing it. Waits *always* occur. It’s the way SQL Server’s scheduling system works.<\/p>\n

A thread is using the CPU (called RUNNING) until it needs to wait for a resource. It then moves to an unordered list of threads that are SUSPENDED. In the meantime, the next thread on the FIFO (first-in-first-out) queue of threads waiting for the CPU (called being RUNNABLE) is given the CPU and becomes RUNNING. If a thread on the SUSPENDED list is notified that it’s resource is available, it becomes RUNNABLE and is put on the bottom of the RUNNABLE queue. Threads continue this clockwise movement from RUNNING to SUSPENDED to RUNNABLE to RUNNING again until the task is completed. You can see processes in these states using the sys.dm_exec_requests<\/em> DMV.<\/p>\n

SQL Server keeps track of the time that elapses between leaving the RUNNING state and becoming RUNNING again (called the “wait time”) and the time spent on the RUNNABLE queue (called the “signal wait time” – i.e. how long does the thread need to wait for the CPU after being signaled that its resource is available). We need to work out the time spent waiting on the SUSPENDED list (called the “resource wait time”) by subtracting the signal wait time from the overall wait time.<\/p>\n

A great resource is the whitepaper on wait statistics: SQL Server Performance Tuning Using Wait Statistics: A Beginners Guide<\/a>, which I encourage you to read. There’s also a much older whitepaper (Performance Tuning Using Waits and Queues<\/a>) which has a lot of useful information, but it’s pretty dated now. The best guide to what the various wait types (and latch classes) mean are\u00a0my comprehensive waits<\/a> and latches<\/a> libraries\u00a0and the\u00a0methodology of using and understanding wait statistics is described and demonstrated in my\u00a0Pluralsight online training course<\/a>.<\/p>\n

You should also check out the following categories on my blog for more along these lines:<\/p>\n