Unsolved
This post is more than 5 years old
13 Posts
0
1731
VMware Performance - Documentum
Hi everyone,
Below is an e-mail discussion that might be interesting for the larger audience.
_______________________________________________________________________________________________________________________________
"The client I’m working with is experiencing unexplained performance impacts to their three Documentum (DCTM) environments. We have looked at and are continuing to look at the DCTM application and its infrastructure to make sure the application has been correctly written and sized. The client heavily leverages Vmware and I’m looking for some help/guidance to validate the VM side of things."
Your few lines could potentially get us talking for days ! I expect a lot of different views coming in after this one ; )
Below my 2 cents :
Q: Do you have a calculation for estimating VM sizing specs to equate to a physical server?
R: Taking into account that the specs for your physical server have been provided by the ISV, who has oversized to make sure there would be enough on the long run, my recommendation is as follows :
- Make the VM as large as the ISV requested (Cpu/RAM)
- Monitor the VM performance charts for unused resources or lack of resources
- Resize (up or down) the VM based on the actual needs of the customer environment based on measured performance data
It is way easier to add/remove CPU/RAM/Disks to a VM than to a physical server => Virtual is better than physical !
Q: For example, if I have a physical server requirement of:
- 2 - Dual Core 3 Ghz CPU (Intel)
- 2,816 MB RAM
R: 4 vCpu /3 GB RAM => which looks a bit silly to me as we know that most systems require more memory than cpu. I would not be surprised that the VM actually suffers from co-scheduling issue and lack of memory.
A better approach would be to start with 1 vCpu and add as needed based on measured performance data in vCenter.
Q: What does the physical server equate to in a VM environment that is running DRS?
I’m looking for help with the following:
- 1. Would DRS impact performance when it migrates the application to available resources?
R: there might be a very short impact at the time when the Vmotion process is initiated (“snapshot” of memory is taken) but, unless the VM would be extremely active with its memory and the VMotion link would be undersized, that should not be noticeable.
- 2. Has anyone experienced sporadic performance issues using Vmware DRS and a DCTM application?
R: DRS : only where the entire cluster has been so overloaded that even DRS couldn’t make something good of it. -> good design and capacity management recommended.
No personal experience with DCTM yet - sorry : (
Q: What is the performance degradation between a physical server and a VM?
R : Depending on the platform used (newer Nehalem/westmere cpu vs “old” xeon – NPT/EPT used - …) performance degradation should be really limited (5-10% max) unless the application would be really unusual.
Main performance degradation would be due to a bad sizing and/or design rather than virtualization itself. Lack of knowledge about VMware would potentially lead to performance degradation (like giving 8vCpu to a single threaded app)
Q: What are the rules for sizing a VMware environment? The client heavily leverages VMware and has hundreds of VM’s (312) running against 18 hosts. Does this sound logical?
R : IT DEPENDS : )
312/18 = 17:1 ratio => I’ve seen much higher (30:1) and much smaller (5:1 – older configs)
What is running on top ? What type of servers are used ? …
A best practice would be to run VMware capacity planner against the physical servers to be able to size the virtual infrastructure based on data and not guts feeling.
If it already runs virtual, VMware capacity IQ would be a good structural approach for capacity management at VM and Cluster level.
Q: How do I validate that using a VM environment with DRS is not contributing to a performance problem?
R: easy : disable it temporarily by setting it to manual or go to advanced settings and disable DRS at the VM level. Personally, I doubt that DRS would be the cause of the performance degradation.
I would first recommend that you check the performance counters at the VM level. A quick list of usual suspects (not exhaustive) :
- CPU
- Ready time high ? (vCenter perf graph – cpu – chart options – select used and ready – “ready” should be much lower than “used”)
- If high -> you have a CPU resource issue
- Maybe assigned to many vCpu that are unused or too many VMs for not enough CPU cores
- If high -> you have a CPU resource issue
- CPU load distribution across vCpus ? (vCenter perf graph – cpu –check that the load is equally distributed across vCpus)
- Memory
- Ballooning ? (vCenter perf graph –Memory – balloon should be = 0)
- Swapping ? (vCenter perf graph – Memory – chart options – select SWAP in +swap out – Swap should be =0)
- If ballooning or swapping is active it generally means you don’t have enough physical memory on the ESX server
- If ballooning or swapping is active it generally means you don’t have enough physical memory on the ESX server
- Active memory High ?
- May need to add more memory to the VM
- May need to add more memory to the VM
- Disk performance
- Disk latency (at ESX level - vCenter perf graph – disk – chart options – select latency counters)
- Latency below 10 ms => fine
- Between 10 ms and 30 ms => worth looking at it
- Above 30 ms : have to look at storage config !! Go FAST – Meta – FAST CACHE – EFD – add spindles - whatever it takes to pump more IO to the server ! ; )
- Latency below 10 ms => fine
Q: On another note, the client has implemented in Production, a FAST Index server on a VM, which is not a supported installation as stated by EMC|Documentum. The client would like to know why this is not supported. Can you shed some light on the reason why this is not supported?
R : (quoting IIG person) : “Our search system currently uses FAST (Microsoft) which in fact does not work under VMware. This has been completely clear for literally years. The remaining elements are supported. We will replace FAST late this year with our own search offering so all elements will them be able to run in virtual environments.”
Best regards,
De Witte Eric
vSpecialists Team Leader EMEA North