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

Measuring "workload" in SQLServer Expand / Collapse
Author
Message
Posted Tuesday, July 20, 2010 9:56 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, September 10, 2010 11:31 AM
Points: 12, Visits: 16
I'm trying to get a handle on what constitutes a measure of work (to calculate comparative "workloads") in the SQLServer environment. The answer "all of them" is probably neither usable nor correct. How about transactions/sec (from dmv sys.dm_os_performance_counters)?
Others ... ?
Post #955718
Posted Tuesday, July 20, 2010 11:03 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 17, 2014 11:06 AM
Points: 101, Visits: 283
We use batch requests per second in PerfMon. On our busiest system, we have 1500-3000 batches per second occurring 24/7.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
Ramblings of a DBA (My SQL Server Blog)
Subscribe to my blog
Post #955765
Posted Tuesday, July 20, 2010 11:10 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 12:07 PM
Points: 15,562, Visits: 27,940
It really kind of depends on your business and your systems. For example, I work for an insurance company. We don't do umpty-gazillion transactions per/second, so measuring just transactions per second wouldn't supply us with much information. Instead, more often than not, we look at query execution time. But even that is not enough of a measure. Instead of finding a single number and deciding that's your point of entry, I'd suggest just a few measures. Base everything on waits and queues. Disk Queue Length, Processor Queue Length and various system waits. Gather those metrics and you'll have a good idea of the performance of the system. Anything else is just a symptom. Transactions/sec went down... why? We have an increased disk queue length. Uh, oh, IO issues. See what I mean?

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #955771
Posted Wednesday, July 21, 2010 7:24 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, September 10, 2010 11:31 AM
Points: 12, Visits: 16
I totally agree. I should have said this is an OLTP system, not OLAP. Queue length and system waits are great performance metrics, but I'm looking for workload metrics. Different but not totaly opposite.
Post #956339
Posted Wednesday, July 21, 2010 7:25 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, September 10, 2010 11:31 AM
Points: 12, Visits: 16
Thanks Tara, and there just happens to be an article on using powershell to capture perfmon statistics in one of my emails this morning: http://www.simple-talk.com/sql/database-administration/gathering-perfmon-data-with-powershell/?utm_source=simpletalk&utm_medium=email-main&utm_content=Perfmon-20100712&utm_campaign=SQL
Post #956340
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse