BCA1548: Oracle on VMware Panel Discussion – This session will be moderated by Don Sullivan and it will be a 60 minute panel discussion in which we have invited 5-6 major elite experts from our customer base to answer your questions. We are requesting that you all submit questions on the below themes. If your question is selected you will be referenced when the question is read to the panel. Below are the few themes which you can send your questions.
- Functional benefits you can't get anywhere else.
- RAC benefits without RAC cost and complexity.
- It's just a server.
- Simple and easy to try.
- Exceptions exist but they are rare.
- These guys don't agree on much, but they agree that virtualizing Oracle is good for your job.
- VMware makes IT work better.
This will help us to plan and address them in our live panel discussion. Thank you all for your time.
See you all at VMworld 2011 – Las Vegas.
In this blog I would like to drill down with an actual sizing example based on the information presented in a prior blog here.
Let’s take the generalized equation presented in Figure-1 below and show an actual sizing example:
Figure-1 Shows a Virtual Machine (VM) with 1 HotSpot JVM.
Figure 2 – Shows the generalized memory Sizing equation of all the memory segments shown in Figure-1
- Guest OS Memory is approx 0.5G-1G (depends on OS/other processes)
- -Xmx, is the JVM max Heap Size
- -Xss, is the Java Thread Stack Size, the default is OS and JVM dependent, and it can range 256k-to-1MB.
- The default should be tuned down to a range that doesn’t cause StackOverflow. I often use 128k-192k. Since the default –Xss is high, tuning it down can help save on memory used and given back to the Guest OS.
- Perm Size is an area additional to the –Xmx (Max Heap) value and is not GC-ed because it contains class-level information.
- “other mem” is additional mem required for NIO buffers, JIT code cache, classloaders, Socket Buffers (receive/send), JNI, GC internal info
- If you have multiple JVMs (N JVMs) on a VM then:
- VM Memory = Guest OS memory + N * JVM Memory
Let’s assume that through load testing a JVM Max heap (-Xmx) of 4096m has been determined as necessary.
You would proceed to size as follows:
- Set -Xmx4096m, also set –Xms4096m
- Set –XX:MaxPermSize=256m, you have chosen to use –XX:MaxPermSize of 256m which a common number and depends on the memory footprint of the Class level information within your Java application code base.
- The other segment of NumberOfConcurrentThreads*(-Xss) depends largely on NumberOfConcurrentThreads the JVM will process, and the –Xss value you have chosen. A common range of –Xss is 128k-192k.
- Note: -Xss is OS and JVM dependent; if the stack is not sized correctly you will get a StackOverflow. As noted earlier the default value is sometimes quite large and you can benefit from sizing it down to help save on memory consumption.
- If for example NumberOfConcurrentThreads is 4, then 4*192k => 768k (assuming you set –Xss to 192k)
- Assume the OS has a requirement of about 500m to run as per the OS spec
- Total JVM memory (Java process memory) = 4096m (-Xmx) + 256m (–XX:MaxPermSize) + 4*192k (NumberOfConcurrentThreads*-Xss) + “other mem”
- Therefore JVM memory approximately = 4096m+256m+0.768m + “other mem” = 4352.768m + “other mem”
- Now typically “other mem” is not significant however can be quite large if the application uses lots of NIO buffers, and socket buffers. Otherwise assuming about 5% of the total JVM Process memory, i.e. 5% * 4352.768= 217m, should be enough, although proper load testing should be used to verify.
- This now implies that JVM process memory = 4352.768m+217m=4570m
- Now to determine the VM memory, assume you are using Linux with no other significant process is running on it, only this single Java process, the total configured memory for the VM translates to:
- VM memory = 4570m + 500m = 5070m
- Now next you should set the VM memory as the memory reservation, you can chose to set the memory reservation as 5070m, however over time you should monitory the Active memory used by the VM that houses this JVM Process and adjust the memory reservation to that Active memory value, which could be less than 5070m
NOTE: a common miss-conception is to assume that this –Xmx value is equal to the Java Process memory needed, but clearly as described by the equation in Figure-2 the JVM Memory (or Java Process Memory) is greater than JVM Max heap (greater than –Xmx) and this is due to the other additional segments outside the heap that make up the memory space of the total Java process such as JVM Perm Size, NumberOfConcurrentThreads*(-Xss), and the “other memory” section.
Figure 3 – Shows Figure-1 with an actual sizing example we just discussed above, in order to illustrate amount of memory each segment has been set to.
Thanks for reading.
Java and vFabric Solutions Architect.
The wave of VMware customers looking to virtualize Exchange 2010 on vSphere continues to accelerate. While there have been customers who have chosen not to virtualize the DAG nodes, the reasons were not those we heard of in years past. Today it's not because of performance or high storage IO, in fact most customers believe that the majority of their applications can be virtualized, including their business critical applications. VMware customers who chose to postpone virtualization of their Exchange 2010 DAG nodes mostly did so for one reason: lack of support for vSphere advanced features from Microsoft. Those customers will be pleased to know that this is now a thing of the past.
With Microsoft's latest announcement of enhanced hardware virtualization support for Exchange 2010 customers looking to deploy a virtualized Exchange 2010 environment and take advantage of vSphere features such as vMotion, VMware HA and DRS can do so with full support from Microsoft and VMware. VMware has been officially supporting the use of these vSphere features along with Exchange 2010 DAGs for some time now, as described in our KB article here. The additional support by Microsoft simply validates what we've been promoting since the release of our Exchange 2010 on VMware documentation available here.
As news of this validation and support begins to pick up steam we anticipate that questions will come up as to what are the best practices for making sure your deployments are successful. To help provide our customers with some insight into using these features with their production Exchange 2010 DAG clusters we've put together a whitepaper outlining testing we performed in our labs earlier this year. The purpose of testing outlined in Using VMware HA, DRS and vMotion with Exchange 2010 DAGs was to:
- Validate the use case of combining VMware HA with Exchange DAGs to reduce the time required to re-establish DAG availability.
- Validate the use of vMotion with Exchange DAGs to allow the use of DRS and proactive workload migration while maintaining database availability and integrity.
- Provide guidance and best practices for taking advantage of these vSphere features.
The whitepaper can be found here: http://www.vmware.com/files/pdf/solutions/VMware-Using-HA-DRS-vMotion-with-Exchange-2010-DAGs.pdf
It shouldn't come as much surprise that the results we came up with and documented are in line with what Microsoft themselves are recommending, further validating our results. Additionally this whitepaper will provide guidance for customers looking to use features such as DRS to allow their vSphere environment to efficiently balance workloads and manage resources and VMware HA to provide even higher levels of availability.
This will no doubt begin driving up the number of virtualized DAGs out there, so help out your fellow vSphere and Exchange administrators. Join the Exchange, Domino and RIM VMware User Community!
Alex Fontana, Technical Solutions Architect