Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

SQLOS: Runnable, Running, Wait List Expand / Collapse
Author
Message
Posted Monday, April 7, 2014 3:28 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, July 7, 2014 9:08 AM
Points: 202, Visits: 565
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!

Post #1559288
Posted Monday, April 7, 2014 10:24 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 10:07 PM
Points: 1,151, Visits: 1,591
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.
Post #1559350
Posted Tuesday, April 8, 2014 12:57 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:46 PM
Points: 42,462, Visits: 35,525
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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1559377
Posted Tuesday, April 8, 2014 9:41 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, July 7, 2014 9:08 AM
Points: 202, Visits: 565
My guess is the credit card authorization guy would go first. Thanks for explaining the logic though!
Post #1559547
Posted Wednesday, April 9, 2014 2:15 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:46 PM
Points: 42,462, Visits: 35,525
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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1559824
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse