Posted by: MikeLaverick
when relevant content is
added and updated.
I woke up on the last day quite tired. Met Sandy down in the lobby (we turned out to be staying in the same hotel) and got a taxi with all gear to the convention center. I head off to the very long titled breakout session called [deep breath] Virtualizing I/O Intensive Application using VMWare: A Microsoft SQL Server Case Study.
I know practically zip about SQL, and you know I’m more than happy for that to remain that way. But what I am interested in is performance. One of THE most common question I get from my students is should I virtualize [insert application server name]. You know like should I virtualize citrix, sql, oracle, sap…. and so on and on. This session was presented by a chap from Brocade – and I was looking for some real stats independent from VMware that would give me some ammo in the classroom – to back up my answer of YES, unless its some huge 8-way or 16-core box which is using 32GB of RAM. Brocades tests were relatively modest – singe CPU VMs with 2GB of RAM. That’s a profile which doesn’t really reflect the common physical hardware assigned to SQL on a PM. None the less the result were very good – and Brocade are promising more research. Ironically, they discovered their SAN configuration was the cause of an unexpected bottleneck. Additionally, some (but not all) of their CPU stats were skewed. I asked them whether this was because they were running performance collections inside the VM (a common novice like mistake). It turned out that there is some kind of flaw/error/bug/deficiency in the collecting performance metrics from VMware. That’s a little worrying – apparently VMware aware of this and there will be a patch. I should have really got hold of this guys contact details so I could have pursued this further.