High CPU Waits but medium CPU Usage

Question

Hi All,
I'm currently checking one SQL Server after our users complained about poor application performance.
In the Data Collection Report, I can see that most of the waits come from the CPU. However, the average CPU load is just between 30% and 50%. What could be the cause for this?
The queries which generate most of the CPU wait time are SELECTs to a view with around 30 columns (decimals) and 30.000 row and the INSERTS to the tables behind the view. Since the physical ready are 0, I guess the results come all from memory.
How could I reduce the CPU waits? Thanks! 
Greetings,
  Theodor

Answer 1

>Could you explain why you think that showing CPU utilization as waits is a *good* thing? 
In performance analysis you care about reducing the elapsed time.  Including CPU use as a wait gives you a unified view of the relative importance of CPU and the other waits.  Otherwise you can't know whether to focus on reducing, say lock waits,
IO waits or CPU use. 
> I don't see anything to fix!
Yes SOS_SCHEDULER_YEILD and Signal Wait Time are both fine.  Those indicate global CPU pressure, ie not having an available CPU to do the work that's ready to be done.
Here the problem is CPU Consumed, which is simply queries chewing up CPU.  So look at the queries, find the queries that account for the most CPU and analyze them.  Looking for instance for unnecessary table scans on tables in memory, inefficient
joins, running moderately expensive queries too frequently.
I really can't follow that.  A wait is when you really are losing elapsed time for external reasons.  CPU or reads are what your code really needs to do.  Very different categories and should not be added, and that's why they
are tracked separately inside of SQL Server.
OP is asking about 9 millisecond transactions.  In most systems I work on, that's already very quick.  I've worked on maybe one system in the last few years where the average transaction was faster than that because of the way it was architected
(we called it "chatty"), most OLTP systems I've worked on in recent years are in the 1000++ millisecond ranges and we consider that excellent performance given what we ask of it.  If that is reported as a "wait", I could make no sense out of such a report. 
As you point out, the DMV report is much more useful.
Fortunately we can break out the numbers and separate the waits from the uses, but I think that SQL Server waits report is highly misleading.
Josh