After upgrading VSAN 5.5 to VSAN 6.0 I thought it would be a good idea to run the same set of tests that I ran previously (VSAN 5.5 Performance Testing) to see how much of a performance increase we could expect.
The test was run using the same IOAnalyser VMs and test configuration, on the same hardware. The only different was the vCenter/ESXi/VSAN version.
Read Only Write Only Real World
VSAN 6 IOPs (Sum) 113,169.88 28,552.85 38,658.47
VSAN 5 IOPs (Sum) 61,964.81 5,666.06 24,228.98
The detailed test results for VSAN 6, using a “Real World” test pattern (70% Random / 80% Read) as below:
Great increase in IOPs!
I recently carried out some VSAN performance testing using 3 Dell R730xd servers:
- Intel Xeon E5-2680
- 530GB RAM
- 2 x 10GbE NICs
- ESXi5.5, 2068190
- 800GB SSD (12GB/s Transfer Rate)
- 3 x 4TB (7200RPM SAS disks)
On each of these hosts I built a IOAnalyzer Appliance (https://labs.vmware.com/flings/io-analyzer) (1 with it’s disks placed on the same host as the VM and the other 2 with “remote” disks). Something similar to this:
IOAnalyzer will boot and attempt to acquire a DHCP allocated address, if this process fails you will need to configure a static IP. To do this complete the following steps:
Log onto the appliance (via the vSphere Remote Console) with the username: “root” and password “vmware”:
Wait until the terminal displays the following error:
Host memory is a limited resource. VMware vSphere incorporates sophisticated mechanisms that maximize the use of available memory through page sharing, resource-allocation controls, and other memory management techniques. However, several of vSphere Memory Over-commitment Techniques only kick-in when the host is under memory pressure.
Active Guest Memory
Amount of memory that is actively used, as estimated by VMkernel based on recently touched memory pages so it is what the VMkernel believes is currently being actively used by the VM.
The following is a description of some common ESXi and VM CPU Performance Issues:
High Ready Time
Ready Time above 10% could indicate CPU contention and might impact the Performance of CPU intensive application. However, some less CPU sensitive application and virtual machines can have much higher values of ready time and still perform satisfactorily.
High CoStop (CSTP) Time
CoStop time indicates that there are more vCPUs than necessary, and that the excess vCPUs make overhead that drags down the performance of the VM. The VM will likely run better with fewer vCPUs. The vCPU(s) with high CoStop is being kept from running while the other, more-idle vCPUs are catching up to the busy one.
vCPUs are always in one of four states (vCPU States):
WAIT – This can occur when the virtual machine’s guest OS is idle (Waiting for Work), or the virtual machine could be waiting on vSphere tasks. Some examples of vSphere tasks that a vCPU may be waiting on are either waiting for I/O to complete or waiting for ESX level swapping to complete. These non-idle vSphere system waits are called VMWAIT.