August 2010 - Posts

An often neglected part of Consolidation is the network configuration of a server. If you have mirroring set up this is particuarly important because the network throughput can be in the same magnitude of the transaction log throughput. Generally if I am limited to four NIC's available I will team two and make them available for general application access, allocate one to an external backup device (iSCSI or a CIFS UNC path) and one for a dedicated connection to the mirrored server. This kind of configuration is for a very basic setup. If there are replication topolgies in place or a scaled out BI Infastructure on a bigger server I would also look at dedicated NIC's for this kind of trafiic. I always set my network cards to Full Duplex.

To get round the issue of legacy applications that dont support the failover partner syntax with mirroring, I often use DNS aliases that I talk about in my previous blog post. When I'm utilising mirroring over a WAN and I want to reduce the network sent over the very precious WAN link, I will disable encryption and utilise riverbed hardware as mentioned here. To force the routing of traffic via a dedicated DR connection I make an entry in windows hosts file for the mirrored server.

While this is not meant to be an exhaustive list, but it does illustrate a few best practices i've discovered. If anyone has any more tricks they would like to share, please let me know.




Posted by blakmk | 2 comment(s)
Filed under: ,

Following on from my comments about CPU configuration I have decided to restate my position to "it depends....". 

Having performed some investigation in the Sql community, Glenn Berry ( Twitter | Blog )  suggested that Hyper Threading should be enabled for the new Xeon 55xx, 56xx, 65xx, and 75xx (Nehalem)  processors and pointed me in the direction of the TPC-E benchmarks for evidence of their performance.

According to the benchmarks in this article  OLTP systems (TPC-E) benefit from a 30% performance gain from hyperthreading while Data Warehousing  (TPC-H) benefitted only 10% from hyperthreading.

Still concearned about the potential issues with Hyper-threading I descided to investigate further. I found this great article by Joe Chang suggesting that many of the problems with the original Hyperthreaded Netburst processors have gone away with the advent of Nehalem. He just suggested setting MAXDOP to 4 as a general rule.

Given that there is such a great performance gain to be had for Hyperthreading with OLTP, I do intend to turn it on for servers containing the new Nehalem chipset. For DW servers, I will still leave it disabled as I have spent many an hour tracking down various issues with CXPACKET and Intra Query Parallel Thread Deadlocks. I still dont trust the technology enough to go there at this point.




Posted by blakmk | 8 comment(s)