February 22, 2012 at 5:36 am
hi all
i have just started a new job and we are soon to be migrating to sql 2008 from sql 2005.
the current setup was done way before my time here so i have no idea how the san is configured raid wise that store the db's and logs (3rd party controlled)
we get lots of pagelatches_sh and i find queries etc run alot slower than my previous post - the main difference is although this has 3 times the memory, is that it runs on vmware.
i can see that the data and log partitions are vmdk files residing on the one RAW lun of the san. and the tempdbs reside on the same partition as the os
i am no virtualisation experts or novice for that matter, but this goes entirely against my school of thought of how sql should be setup - i am used to setting up dbs on raid 10 , logs and tempdbs on seperates raids - best available considering disk availability..
personally id like to remove sql from vsphere and get it running on a standalone physical server, it runs on its own host anyhow, so i fail to see why getting vmware to control the processor/memory etc etc adds anything benefactor y? apart from the redundancy side of things and ease of manageability which i assume is the only things the 3rd party took into consideration
can anyone help me sort my thoughts out? what would you recommend?
February 22, 2012 at 6:09 am
Virtualization of the server adds a layer of processing and is therefore slower, no matter what.
That said, there are a bunch of reasons to use virtual machines in different environments and for different purposes, so you're going to see virtualization get used, and it's a good thing.
But, you need to change how and what you monitor. You're correct to be looking to the disk because that part of the process doesn't change. All the standard counters for measuring disk performance still apply. You can also look at query execution time. But for monitoring memory and CPU, you need to monitor from the physical box, not the virtual server. That's the one big difference.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 22, 2012 at 6:21 am
hi Grant
good point on the monitoring..
i really dont think its a memory issue as it has 26gb of ram- which is relative i know- but i have seen just as data intensive sql servers run on 8gb equally as well, and if the cpu is an issue then surly virtualising it is only an overhead also? we are only licensed for 1 cpu so i cant fire more cores at it!
February 22, 2012 at 6:32 am
In my experience with virtualization (limited), even a brand new VM with a fresh install of SQL can appear to be "slow", yet monitoring things like CPU/RAM/DISK usage reveal litte if anything at all as to why the server/SQL runs slow. I would assume it leads back to how the Sytem Admin configured the VM Server (not so much the host)?
I always opt for physical servers for production SQL boxes and use VM's for the more lesser SQL servers in our company. Since MS is changing it's licensing practices for VM's soon anyway (going to licensing individual cores rathan than physical socket) I personally don't see much of an advantage using a VM for production needs.
Just my .02 :w00t:
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 22, 2012 at 6:42 am
Stuff like ESX Replication[/url] and DoubleTake make VMs pretty hot. There are whole lot of other management aspects to VM that make them great. My personal take is, unless you can specifically define why a particular system needs to be bare metal, I'd put stuff on VMs, assuming you're already managing VMs within your space and have the required expertise. Some other reasons to virtualize.[/url]
Just make sure you read the appropriate virtualization management software best practices document. Here's the one for VMWare.
By the way, I come off like a VM fanboy, but I'm not. I just think there's a lot of Fear, Uncertainty and Doubt out there and I want to dispel that. There are many reasons why you should NOT virtualize too.[/url]
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 22, 2012 at 6:44 am
dopydb (2/22/2012)
hi Grantgood point on the monitoring..
i really dont think its a memory issue as it has 26gb of ram- which is relative i know- but i have seen just as data intensive sql servers run on 8gb equally as well, and if the cpu is an issue then surly virtualising it is only an overhead also? we are only licensed for 1 cpu so i cant fire more cores at it!
I would absolutely break the storage up. Disks are disks. Putting the data storage into the VM OS storage is just as bad, if not worse, than putting it on the C:\ drive of a bare metal server.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply