Clarification on signal wait percent

Question

I'm experiencing high Signal Wait percent while CPU utilisation is very low at one of our servers.
I have gone through numerous articles online about Signal Waits and understand that it is the time spent on the runnable queue however I'm still having difficult time to understand why CPU usage is staying so low (25%) while Signal Waits' percent is high (band of 75-90%.)
If a session is waiting for an available CPU to run it, why is CPU utilised so low?

Answer 1

Don't tune with percentages. Your server will always have 100% of its waits on something - but there just may not be much load. Your server is the classic example.

Say you only run 1 query per hour. All of the query's data is already cached in memory, and there's no one else competing for locks. That query has several parallel tasks in it, and they all need to get CPU time.

That query's just going to work for a while, then finish. If you looked at signal waits, it might seem like 90-100% of the time, WHEN IT WAS WAITING, it was waiting to get on CPU. But it just wasn't waiting that much.

Instead, look at wait time per core, per second (or per hour) as described here:

https://www.brentozar.com/archive/2015/03/how-to-measure-sql-server-workloads-wait-time-core-second/

(Disclaimer: I wrote that.) That way, you can see if the server's really doing any work at all. I bet in your server, you're only waiting a few minutes per hour - meaning, you just don't need to bother tuning that server overall. It doesn't mean every QUERY is fast - it just means you can't do server-level tuning, and you have to switch to query-level tuning. (You have to ask why the query is slow rather than asking why the server is slow.)