• High Performance
• Balanced
• Power Saver

While it’s hard to perform a “real-world” CPU benchmark test, Glenn suggested I try using the Geekbench CPU benchmark software. The software runs a series of CPU and memory tests and produces a Geekbench Score which provides a standardized way to compare CPU performance.

To find out how much the three OS Power Plan options affected the performance of my T610, I first set the system BIOS in the Dell Setup program to “OS Control.” Dell not only allows you to set the BIOS to “OS Control,” which means the OS controls the power savings, it also includes other power savings options that are not controlled by the OS. I only tested the “OS Control” option.

Test Hardware: Dell T610 Tower, with a single, 6-core CPU (Intel Xeon X5670, 2.93 Ghz, 12M Cache, HT, 1333MHz FSB); 32GB 1333MHz RAM; a PERC H700 RAID controller; two 146GB 15K SAS Drives; one dual-port HBA (to connect to the DAS); and dual network connections.

Test Operating System: 64-bit Windows 2008 R2 (with current patches).

Next, I went to the Control Panel and changed the Power Plan setting to “High Performance”.

When I ran the test using the “High Performance” option, the Geekbench Score was 10,562.

Next, I changed the Power Plan to the “Balanced” setting, and the Geekbench Score was 7,991, a drop of about 24% in performance from the “High Performance” setting.

And last, I changed the Power Plan to the “Power Saver” setting, and the Geekbench Score was 7,075, about drop of about 33% in performance from the “High Performance” setting.

While the OS Power Plan settings affect more than just CPU, it becomes obvious from this simple test that changing the Power Plan can significantly affect a CPU’s performance, which in turn could significantly impact the performance of a SQL Server instance.

Of course, these three power options are available because they allow you to make a tradeoff between performance and power savings. As the DBA, you have to determine if the power saved by running the CPU more slowly is worth the performance tradeoff. The only way to really check this out would be to use a wattmeter to determine how much electricity is saved for each different settings. I don’t have a wattmeter to try this out, but Glenn has reported in some of his testing that the power savings appears to be insignificant, especially when compared to the significant drop in CPU performance between each “Power Saver” plan.

The point of this post is that when your configure your SQL Server’s hardware, you need to investigate what the appropriate “Power Saver” plan your server should be running. Based on this simple, initial testing, I think I’ll leave mine on “High Performance”.

I finally received all the components of my SQL Server test cluster (pictured left), which includes:

–One PowerVault MD3000 DAS with two, dual-port controllers, and 15 146GB 15K SAS drives.

–Two identical Dell T610 Towers, each with a single, 6-core CPU (Intel Xeon X5670, 2.93 Ghz, 12M Cache, HT, 1333MHz FSB); 32GB 1333MHz RAM; a PERC H700 RAID controller; two 146GB 15K SAS Drives; one HBA (to connect to the DAS); and dual network connections.

Before I start assembling the hardware and installing the operating system, I am first setting up an older Dell tower computer I have as a domain controller. In addition, I am configuring a wireless bridge to my wireless network, as the location of my test system is not located near a convenient network connection. Once I have the domain controller and wireless bridge configured and working, then I will begin assembling and configuring the new hardware.

While I was at TechEd, I had a talk with the head of the DBA Tools division at Red Gate Software, and we were talking about software testing when I mentioned that I would like to have my own test hardware at home. And a little to my surprise, he agreed with me. That’s when I started to do some research on what I thought would be an ideal (and still affordable) test box, and that’s when I wrote the above mentioned blog post.

As I was corresponding with the head of the DBA Tools division, he suggested that I also spec out a two-node cluster with Direct Attached Storage (DAS) so that I could test even more scenarios. That was a little more than I was expecting, but I went ahead and put together two proposals: one for a single tower test box, and another with two towers plus a DAS that was configured for clustering. To my surprise, the cluster configuration was approved and I placed the order for it yesterday. Hopefully, in about 30 days, all the hardware will arrive and I can begin to build the cluster and to begin some testing and benchmarking that I have been wanting to do for a long time.

Here is what I ordered:

–Two identical Dell T610 Towers, each with a single, 6-core CPU (Intel Xeon X5670, 2.93 Ghz, 12M Cache, HT, 1333MHz FSB); 32GB 1333MHz RAM; a PERC H700 RAID controller; two 146GB 15K SAS Drives; one HBA (to connect to the DAS); and dual network connections.

–One PowerVault MD3000 DAS with two, dual-port controllers, and 15 146GB 15K SAS drives.

In order to have a proper cluster, I also need a third box to act as a domain controller. Fortunately, I already have a small Dell tower that will now be devoted as my domain controller and be configured so that I can access my network remotely.

While not a huge system, it should more than meet my needs as a home test server, and give me plenty of flexibility to experiment with different configurations. Of course, it is not as big a test system as Paul Randal has, but I think it will do just fine. When I get the equipment and start building the cluster, I’ll blog on the experience. It has been a few years since I built a cluster from scratch, and this should be a good learning experience.

PS: I also want to thank the head of the DBA Tools division, and Red Gate Software, for my new test system.

Below is the current version of my SQL Server hardware inventory/audit checklist, which is in the form of a spreadsheet that can be used not only to collect and store the information, but it can also be customized as needed by DBAs to better meet their environment.

In some cases above, when there are two or more components (such as multiple RAID arrays), a separate column would be used to provide information for each component.

I would really like your input on this list. For example:

–What is missing from the list? What hardware or configuration information should I add? Keep in mind that I can’t include every possible variation.

–What on the list could be removed because it is not very important? Keep in mind that the list is designed to be generic, so there will be items on the list that will not be applicable to all SQL Server environments.

–Does my wording make sense, or should I change any of the wording so that it is more understandable or more accurate?

If you are already using your own hardware inventory checklist, I would appreciate it if you could e-mail me a copy (empty of course) of it to bradmcgehee@hotmail.com. I won’t share the list, but I would like to see how you are keeping track of hardware-related information. Thanks!

–Because I have limited space, the test box will need to be a tower. I will also be limited to one physical test box because of a lack of room (and budget).

–CPU: 2 sockets with a total of at least 8 cores. Haven’t decided on the specific chips yet.

–RAM: At least 36GB. I want to have the ability to set up multiple virtual servers in the test box.

–RAID Controller: Must support RAID 1, 5, & 10, and any mixture of these RAID levels.

–Drives: I am looking at getting 8-16, 15K SAS drives, with a minimum capacity of 450GB each. The number of  drives will depend on what I can fit into my budget, and how many can fit in a tower.

I am still very much in the research stage, so my question to you is, if you could spec out your own SQL Server home test system, and you had $10,000 to spend, what you buy, and why?

PS: If you are a hardware vendor and would be interesting in letting me borrow such a test box from you for the next year or so, I would be very interested in talking with you.