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 over...it'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 techtarget.com. I'll note them Counter