SQLOS: Runnable, Running, Wait List
-
I was reading a Microsoft White Paper (haven't completed the reading yet)
Using the illustration below, why would SPID 56 go back to the bottom of the runnable list?
What if it goes back the bottom of runnable and when it's SPID 56's turn to be running again and it has to wait on parallel process again or some other random resource then it will have to be suspended again and then go back to the bottom of runnable queue again once that resource is available?
I'm new to this and just curious why can't it cut in line in the runnable queue. I would think if we were at a Walmart checkout line and we were being checked out by the cashier, if one of our items to be purchased needed to have a price check, the cashier wouldn't move us back to the end of the line right? Maybe I'm misunderstanding the logic or missing some bigger picture. Thanks!
-
Paul Randall has an explanation here http://www.sqlperformance.com/2014/02/sql-performance/knee-jerk-waits-sos-scheduler-yield
The Waiter List is unordered (any thread on it can be signaled at any time and move to the Runnable Queue) and the Runnable Queue is First-In-First-Out (FIFO) almost 100% of the time. The only exception to the Runnable Queue being FIFO is where multiple Resource Governor workload groups have been configured in the same resource pool and they have different priorities relative to each other. I’ve never seen this used successfully in production so I won’t discuss it further.
Everyone on the runnable queue is ready to go, but are waiting on a scheduler (CPU resource) to become available. For each CPU/core, you'll have a scheduler and the runnable task queue should remain very low for each scheduler. When a task is Waiting it adds to Resource Waits, when a task is runnable it adds to Signal Waits. You can compare resource waits to signal waits and work out whether you have CPU contention.
-
smallmoney (4/7/2014)
I'm new to this and just curious why can't it cut in line in the runnable queue.Because it's no more eligible to run than any other process. If it kept cutting in front, you could end up with thread starvation, where nothing except 56 gets to run or where 56 got way more time on the processor than anyone else.
Say your supermarket queue had 1 person who needed a price check, one who asked for cigs to be fetched for him (here they have to be fetched by someone), one has a credit card which required authorisation and one forgot an item. They've all now got what they needed and are just waiting for the cashier to be free. Which is going to go first?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
My guess is the credit card authorization guy would go first. Thanks for explaining the logic though!
-
smallmoney (4/8/2014)
My guess is the credit card authorization guy would go first.I would hope not. I would hope that the first person who was ready goes first. Otherwise, you could have one person continually pushed back in the line because there's someone else who has higher priority. That's thread starvation (or in the retail world a really pissed off customer)
Unless Resource Governor is configured, all threads have equal CPU priority and hence no thread should ever be able to jump the runnable queue (doing so would imply that the thread jumping the queue is more important)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply