vm tuning for opscenter performance optimization -...

VM tuning for OpsCenter performance optimization 1

VM Tuning for OpsCenter Performance Optimization

Bhalchandra Namjoshi Director: Development

Roadmap Disclaimer!

• This forward-looking indication of plans for products is preliminary and all future release dates are tentative and are subject to change. Any future

release of the product or planned modifications to product capability, functionality or feature are subject to ongoing evaluation by Symantec, and

may or may not be implemented and should not be considered firm commitments by Symantec, and should not be relied upon in making

purchasing decisions.

2 VM tuning for OpsCenter performance optimization

Agenda


Factors affecting OpsCenter Performance 1

VMware Resource Consideration 2

Test Environment 3

Observations 4

Recommendations 5

Factors affecting OpsCenter performance

• Software

– DB size

– DB cache size

– JVM size

• Hardware

– CPU

– RAM

– Disk I/O


VMware Resource Considerations

• Memory

– ESXi memory is used to hold the ESX code as well as the VMs

– If ESXi cannot find enough free memory, it invokes the balloon driver in the GOS of one or more VMs

– If this fails to free up enough memory, ESXi itself begins to swap at the host level

• CPU

– ESXi allows significant levels of CPU over commitment

– If an ESXi host becomes CPU saturated, latency-sensitive workloads might not perform well

– Unused vCPUs still consume timer interrupts in some guest operating systems

– CPU Power Management Policy affects the performance


Parameter Value

ESXi version 5.1

No of VM’s on the ESXi 5 (including OpsCenter VM)

OpsCenter version 7.6

OpsCenter DB Static DB ~30 GB on SAN datastore

Operating System Windows Server 2008 R2 Enterprise

CPU 8 Logical (4 * 2 Cores)

(Installed Physical Memory ) RAM

24 GB

Windows Paging size 18 GB

Test environment


Test conditions

• Data collection

– Static data. No data collection.

• Reports tested

– 6 Reports from Top 20 reports

• Logging

– Normal


Observations – I

• Availability of the CPU cycles to OC VM : High impact

• Disk I/O : High impact

• Availability of the RAM : Medium impact

• Memory consumption increases when data collection happens

• CPU consumption increase if your report has more number of ‘join’


Observations - II

• After reserving the CPU and Memory for OC VM, total report generation time is improved by 32 % in the event of ESX CPU reaching to 100% Vs VM has no reservations set and limit was set

• Even though CPU and memory are reserved for OC VM; actually VM do not get adequate or all the allocated CPU cycles when the ESX CPU reaches to 90-100% . In this case ESX has stolen the CPU cycles from the OC VM and in turn impacted the OC performance.

• Performance was degraded by 11% when the CPU cycles were stolen by the ESX


Recommendations - I

• Reserve x CPUs and x GB of RAM for OpsCenter VM

– Refer the OpsCenter sizing sheet to decide on the optimum values of CPU and RAM

• Do not install other Java applications on OpsCenter VM

• Ensure that ESX on which OpsCenter VM is running is not overloaded in terms of CPU, Memory and Disk space usage

• Select optimum CPU Power Management Policy based on your requirement

• Make sure that Operating System swap and VM swap does not reside on a datastore where database resides


Recommendations - II

• Install the OpsCenter database on a drive that is different from where OpsCenter server software and operating system is installed. This drive should be on datastore which is on dedicated LUN

• VMware snapshots increase the I/O heavily. Try to avoid snapshots.

• You may use RDM disk for database.

– NBU cannot backup VM’s with RDM disks. You may think of RD for VMware in this case.

• Save the OpsCenter log files on a drive other than one where database is installed to reduce I/O

• If possible, database should reside on RAID 5

• Align file system (VMFS) partitions to 1MB


Report Name Average Time (Min)

NON reserved

Average Time (Min)

NON reserved

# of records

All failed backup Report 3.18 2.41 12046403 rows

603 pages

Virtual Client Summary Report 0.02 0.01 2889 rows

29 pages

Job Success by client -tabular Report 2.48 1.37 7498 rows

75 pages

Advance Success rate Report 1.30 0.90 125 rows

2 pages

Clients not backed up Report 0.06 0.05 15720 Rows

158 pages

Skipped Files summary Report 0.12 0.11 282 rows

3 pages

CPU and Memory reserved VS non reserved


*with 8 CPU 24 GB RAM on VM - CPU Centric Operations on other VM's

Report Name Average Time (Min)

CPU Centric Operations

Average Time (Min)

No-CPU Centric Operations

# of records

All failed backup Report 2.41 2.02 12046403 rows

603 pages

Virtual Client Summary Report 0.01 0.01 2889 rows

29 pages

Job Success by client -tabular Report 1.37 1.22 7498 rows

75 pages

Advance Success rate Report 0.90 0.87 125 rows

2 pages

Clients not backed up Report 0.05 0.04 15720 Rows

158 pages

Skipped Files summary Report 0.11 0.10 282 rows

3 pages

CPU centric VS No-CPU centric operations


*High ESX CPU utilization: 90-100% (CPU centric operations on non OC VM’s) VS Low ESX CPU utilization: 20 %

Thank you!

Copyright © 2013 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice.


Bhalchandra Namjoshi

[email protected]

+912066157904

vm tuning for opscenter performance optimization -...

Documents