Runnable, Running and Suspended

Runnable, Running and Suspended

When you send a query to SQL to be executed, the query is compiled and then run. When you have 1 person querying the database, everything runs fine, but when you ramp that up to multiple users, you start to fight for resources. One of those resources is CPU.

To manage CPU time, SQL Server tracks tasks in 3 basic states – Runnable, Running and Suspended.

Runnable: This is the default state of a new task that comes to SQL. Runnable means that it is ready to run, it has all the info it needs, and it’s just waiting for the CPU to be free. All of the tasks in a runnable state are queued up and taken in order to be run.

Running: This is the state when the task is being run by the CPU. SQL Server is actually doing the work that the query has asked. There are 3 normal ways that a task can stop being running:

1. It completes
2. It has to wait on another resource (like reading data from disk)
3. It has been running for 4ms

Suspended: This is the state when your task has been removed from the running state, either because it’s 4ms is up or it is waiting for a resource other than CPU. It might be waiting on Locks, Disk IO, Network Traffic, Synchronous Commits in an availability group, or a huge range of other things. Once it has finished waiting, the task will be sent back to the Runnable queue, to wait for some more CPU time.

One of the biggest takeaways for me when I first learnt about this, was that the task is only running for 4ms at a time. Your task cannot tell SQL that it needs more time, it cannot tell SQL to just hang on for another couple of milliseconds because I’m almost done.

As you start to look in to making your server perform better, understanding the different states of tasks becomes important so you know where to look. Do you have a million tasks in the runnable state? You might need more CPU. Do you have an empty queue in the runnable state? You might need less CPU (less licenses/cloud resources). Do you have a heap of tasks in the suspended state? You might want to look at what is holding up those queries, throwing CPU at your server might not be the solution.