on 02-11-2016 2:55 PM
Is there any documentation about spinlock contention on "Sched Q" ?
Thanks
Mike
Contention on Sched Q is due to ASE engines doing task stealing. Think of it this way - each ASE engine checks local queue and then checks global queue for each priority of task (e.g. local HIGH, global HIGH, local MEDIUM, global MEDIUM, local LOW, global LOW) - if nothing found, it checks the local run queues of other engines. As a consequence, if you have a lot of engines that are essentially idle, they can be beating each other up by trying to check everyone else's local run queue. ASE 16.0 added new config "aggressive task stealing" - which defaults to 1 and I suggest setting to 0 for anyone with more than 12+ engines.
However, as with MOST spinlocks (if not all), the spinlock contention is OFTEN a symptom of a problem and not the cause. For example, check where the relative position of tablockspins or check the disk IO queue. If there are a lot of processes WAITING - then the engines are more idle than they should be and hence they get into the nasty aspect of task stealing. While disabling aggressive task stealing is a start - the REAL solution is to find out and eliminate why they are waiting. A most common problem is that the lock promotion thresholds are far far far far too low (and often at the defaults) and consequently all too often one spid escalates to a table lock (shared or exclusive) and blocks others - the blocking is the issue - the tablockspins (table lock spinlock) is an indicator as well as WaitEventID=150.
In reality - anything that drives wait time can be a contributor to run queue spinlock contention - whether locking/blocking, disk IO (e.g. slow reads are also very frequent when using SANs), or any of the other 600 reasons in monWaitEventInfo.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I guess I should have been more clear, but I thought it obvious from the name - Sched Q spinlock is the spinlock that protects engine run queues.
Also - "aggressive task stealing" may have been back ported from ASE 16 to later revs of 15.7 - you might want to check your release. If not, sorry....yet another feature in 16 not in 15.7.
Hi Mike
I was asking myself the same question right at this very moment...
Have you found out anything yet ?
It looks like a lot of these different type of spinlocks are undocumented
Thanks
/Mike
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.