Unsolved
This post is more than 5 years old
256 Posts
0
937
December 5th, 2011 18:00
What is the realistic performance difference between physical and virtualized Oracle?
The definitive document on virtual vs. physical performance of Oracle databases (at least in a NAS context) states that the difference between physical and virtualized performance is around 12%. This EMC proven solutions document contains the following stats:
| Description | Result |
|---|---|
| Physically booted TPS (with FAST Cache) | 402,226 |
| Virtualized TPS (with FAST Cache) | 354,611 |
| Difference | 11.84% |
Personally I found this result dubious at best. This is because the purpose of the document was to show the maximum effect of FAST Cache. In the process, the testing folks cramped the SGA to force all Oracle transactions to go to disk. This means that the disk I/O subsystem (using Direct NFS in this case) was very stressed, and was always the bottleneck. Thus, I consider this an unreastic test in terms of the difference between physically booted and virtualized performance. After all, the disk I/O subsystem is not usually this stressed. Generally, we configure enough SGA to cause most of the transaction activities to occur in the cache, not directly to disk.
Hence my question: I am interested in the real-world experience of folks who have run Oracle in a virtualized context (especially using good-old vSphere). If you have tested performance of your workload using both physically booted and virtualized servers, and have some results to share, then we would love to hear from you. Please let us know.
dba_hba
63 Posts
0
December 6th, 2011 04:00
Jeff
I have just read this post quoting the VNX FAST Cache use case and would like to clarify on a couple of points
The SGA is in this solution is clearly not cramped on either the physical or virtual configurations. This paper was produced by the EMC Proven Solution team and did not use this technique to drive extra load at the storage.
Here is how I see the results
The physical RAC environment was 2 servers each with 4 x 8core CPU and 128GB of memory. Each node having an SGA of 50GB. So the physical solution has 64 cores and 256GB of memory assigned and used.
The virtual RAC environment has 4 VMs with 8 vCPU and 32GB of memory. Each node 24GB SGA. The underlying ESX servers mirror the server used in the physical RAC environment, with 64 cores and 256GB of memory.
Ignoring hyperthreading and keeping it simple where 1 vCPU= 1 core, the virtual RAC solution uses 32 vCPU (cores) and 128GB of memory, 50% of the CPU and Memory resource of physical RAC configuration for 88% of the performance. This leaves 32 cores and 128GB available for other virtualized solutions.
This virtual solution was built is with minimal changes to default Oracle settings and tested on ESX 4.1 so the 8vCPU limit still applies. I am certain that even better performance could be achieved
I guess the url below was the previous definitive whitepaper (Feb 2011) on virtual vs. physical performance of Oracle databases (on block at least). It shows what can be achieved when virtualizing Oracle on VMAX with FAST VP and shows virtual and physical performance within 2- 4% of each other.
http://www.emc.com/collateral/hardware/white-papers/h8123-oracle-rac-symmetrix-fast-vp-vsphere-wp.pdf
I am sure that we will revisit aspects of these solutions in future papers on vSphere 5. In the meantime there is a wealth of recent collateral and discussion from EMC and VMware on virtualizing Oracle
Oracle RAC on Vmware vSphere Deployment guide
http://www.vmware.com/files/pdf/partners/oracle/vmware-oracle-rac-deploy-guide.pdf
EMC IT's Virtual Oracle Deployment Framework
https://community.emc.com/docs/DOC-12914
Combo: Tuning Latency Sensitive Workloads by VMware & VMworld PPT
https://community.emc.com/thread/127358?tstart=0
dba_hba
63 Posts
0
December 8th, 2011 04:00
Jeff
As discussed, without cramping either physical/virtual SGAs, we managed to more than double the TPMs for the Swingbench workload in both the physical and virtual use cases.
In this use case, almost the same amount of memory was allocated to the SGAs
physical SGA = 2 x 50 = 100GB
virtual SGA = 4 x 24 = 96GB
In the virtualized use case, I believe that Global Cache waits are actually responsible here for a large part of the 12% difference and it is partly down to the Swingbench application andthe difference in running it over 2 and 4 nodes. Some of the gc waits may be reduced by partitioning the Oracle tables, especially the Inventory table which is constantly updated.
Now that vSphere 5 is here a better use case would have fewer nodes with more vCPU in each and partitioning of the application workload to reduce global cache contention.
The older FAST VP/VMAX paper better shows what can be achieved. The fact that we had time to built and test a number of different VM configurations before selecting the best for testing obviously helped.
I agree that driving IO load through to the storage with a smaller SGA is a valid testing technique. However, our solutions are supposed to reflect "real world" so we are sizing the SGA in such a way that a customer might. Admittedly, a customer with access to brand new servers and an interest in virtualization.
Allan