March 23, 2012 at 3:35 pm
I have used the tool Management Data Warehouse for quite a lot of different clients. One of the reports, ‘Server Activity’ has a section called ‘SQL Server Waits’.
This report part has an interesting concept of modeling the CPU time as if it were a waittype.
The sum of all signal waits (for all wait types) are shown as CPU (Signal Wait).
The report gets the actual used CPU time from perfmon data (the % Processor Time in the process object of sqlserver). This is shown as CPU (Consumed) in the table below the graph.
I think that it should be possible to see if a server is CPU bound or bound to another resource by comparing the ratios of the wait types.
However, the report always has a problem (for the servers that I am looking at), that the CPU ‘wait type’ always has a very high value if looking at an interval of 1 hour or more. If I change the interval to 15 minutes, the ratio of the CPU wait type of the total suddenly drops.
To me this seems like a bug in stored procedure [snapshots].[rpt_wait_stats] (it is very well documented) wich is easy to 'solve'. But for me it seems very strange that a standard product that many people use has such a kind of bug.
Does anyone of you use this report? Do you think this is a good concept? Would it be an indication of a server being CPU bound if the CPU shows up very high in this report?
March 26, 2012 at 6:37 am
Would you mind posting a link to this "very well documented bug"? I'm not finding anything about it. TIA.
=============================================================
/* Backups are worthless, Restores are priceless */
Get your learn on at SQL University!
Follow me on Twitter | Connect on LinkedIn
My blog: http://sqlchicken.com
My book: Pro Server 2008 Policy-Based Management
March 26, 2012 at 12:52 pm
Now that I read my post again I see that my message was not very clear about this. What I meant was that the stored procedure contains a lot of comment in the code itself, which makes it very understandable.
Changing to a different time interval should not have impact on the waits (relative to each other).
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply