Performance Counters - Analysis

I've struggled to find a good source on how to properly interpret performance counters. In our case, it was determining IOPS for a potential SAN we were looking at. I had really been trying to convince the management that we could better utilize our current server-base if we set up a SAN and went ESX for production (we had ESX for testing already). They were not convinced that the SQL servers would fare well under ESX, so I started researching.

I spoke to a number of vendors (Xiotech, Lefthand, EMC, Equalogic), and all of them wanted to know how many IOPS I needed out of the solution. They then of course went on about how many their particular ware allowed, but I digress... I had no idea how to calculate IOPS (I/O per second) requirements, so it was off to the internet to figure things out. One of the vendors offered to decode perfmon logs for me, but I really wanted to know how to do that myself. Besides being a handy skillset to have, it meant much less time spent waiting for others.

I'll have a list of links at the end of this post, as a lot of the info I gleaned was from multiple sources, all quite good in their own respect.

Here goes, and please note that this spec is for an SMB with around 100 users.

First of all - perfmon. It is not advisable to use readings on the fly - set a capture to run with all your desired counters and let it go for a business week (depending on the number of counters, you may need to allow perfmon to use the maximum size of the logs - you can also set a custom size - 4095MB is the maximum).

Exchange calculations
Pulled off Technet, the basics were this:
Based on a heavy user - 60sent/150received,500+MB mailbox), you get approximately 1.5IOPS. Take the number of mailboxes you have (I used a high number of 250 - we'll have around 200 mailboxes when all is said and done) and multiply by the IOPS, so 375IOPS is what we need to have Exchange running correctly with room to grow. Again, my calcs are pretty generous.

SQL calculations
This is a deep, deep pool to wade into...but I really had no other choice.

Basically, I needed to know what our current usage was, because if it is more than the SAN will be able to handle, then it'll clearly be a fruitless effort. (I will also use SQLIO to get our max throughput for a benchmark - thanks D!)

The essentials of a properly running SQL server are:

Hardware setup
  • Dual quads, 8-16GB RAM, 64bit OS (keep in mind that even if you have 16GB of RAM, and you allow SQL to use 15GB of it, then wonder why you have less than 1GB left's because SQL will use as much RAM as you allow it to have - the basis being that it's faster to page to RAM than disk.)
  • Your DBs (databases) are on one array, preferably a RAID1 or RAID10 array with disk caching (pretty sure you can't get a RAID controller these days without battery backed-up caching). This array also has as many spindles as you can spare (for our CRM4.0 rollout the consultants specced 8x146GB 15k).
  • Your transaction logs are on another array, again preferably RAID1 or RAID10 with four disks as above specced.
  • There is a temp array for DB copying, backups, etc, same spec as the logs array.
With that number of disks (8DB,4LOGS,4TEMP,2OS), you're really into a shelf at that point, or some sort of SAN. Also, the reasoning behind RAID1 or RAID10 is with those RAID levels you get more reads, and since SQL is read-heavy you then have better performance.

Performance counters to note
This was all noted right off a series of videos hosted by I'll note them Counter - Instance, if applicable -notes.

Paging - Total use % - Should be less than 70%.
Paging - Peak use % - Same as above, should also be fairly constant.

Processor - % Processor time - All - Should be 80% or less.
If you're troubleshooting the above:
Processor - % Privilged time - All - Should be less than 30% of total % processor time.
Processor - % User time - All - Should equal (100% - % Priv. time).

Memory - Pages input/sec - Should be less than 10.
Memory - Pages/sec - It's okay if this is around 500-600 or less.

SQLServer:Access Methods
- Index searches/sec
- Full scans/sec
If you divide (Index searches/sec) by (Full scans/sec), the number you get should be less than 1000.
- Batch requests/sec
- Forwarded requests/sec - Should be less than 10 per 100 batch requests.
- Page splits/sec - Should be less than 20 per 100 batch requests.

SQLServer:Buffer Manager
- Buffer cache hit ratio - Should be 95% or higher.
- Free list stalls/sec - Should be less than 2.
- Free pages - Should be at least 640, preferably more.
- Lazy writes/sec - Should be less than 20.
- Page life expectancy - Should be at least 300.
- Page lookups/sec - Divide (page lookups/sec) by (batch requests/sec) and it should be under 100.
- Page reads/sec & Page writes/sec - Should be less than 90. If not, could be your indexes or memory constraints.

You get the point. There's a lot to consider.

The consultant we have in has suggested that to get a clearer idea we should get max benchmarks using SQLIO. On the disk array with 6x300GB 15k SAS in RAID5 we got around 1400IOPS max when doing random read/write of different sizes.


This can be considered to be a fairly small part of the equation, unless you add VM access, but that's another category all-together.

I'll post more as I think of it.



Popular posts from this blog

DFSR - eventid 4312 - replication just won't work

Fixing duplicate SPNs (service principal name)

Logstash to Nagios - alerting based on Windows Event ID