VMware Cloud Community
OsburnM
Hot Shot
Hot Shot
Jump to solution

Improving Performance in vCenter

Greetings all--  I'm hoping the community can help me out with this one.  It's related to vCenter performance.

VirtualCenter has gotten to the point where it is VERY sluggish almost all the time and I can't figure out why.  As a couple of examples, when in VMs & Templates view, VC locks up frequently for anywhere from 20 to 60 seconds just selecting one DataCenter to another.  RVTools takes almost 20 minutes to come up.  Also, if I try to install VeeamONE or VeeamBackup, they are slow slow it is not usable and will sometimes bring VC down (so Veeam isn't running-- just wanted to give the example).  Lastly, if I reboot the VirtualCenter server (VM), it can sit at "Applying Computer Settings" for almost 20 minutes.

I support a vSphere environment that consists of the following

vCenter:  5.0 Update 1 - Running on a Win2k8R2 VM with 8vCPUs and 20GB Memory

VC SQL Server:  2008R2 SQL - Running on a Win2k8R2 VM with 8vCPUs and 32GB Memory

VUM:  Dedicated VM

VC Web:  Dedicated VM

* All four run VMs on a dedicated 2-node "Management Cluster" that consist of two HP DL380p G8s with DualProcs & lots of memory. No other VMs run on these host & ready times are all pretty much zero.

This currently manages 316 ESXi hosts (all 5.0 Update 1)  and about 6000 Virtual Machines.  When VC was installed, I selected the "Large" scale as we will be adding about 200 more hosts & about 1000 more VMs over the next year.  The ESXi hosts use the Cisco Nexus1000v (excluding the 2-node mgmt cluster-- those are on standard vswitches).

The hosts & VMs are in about 20 datacenters & 30 clusters, scattered physically across the country (US).

Any thoughts on how to make this better?

Thanks in advance!

Reply
0 Kudos
1 Solution

Accepted Solutions
Troy_Clavell
Immortal
Immortal
Jump to solution

From here, should I run the Purge Old Data script from the other KB or  should I expect to see performance improvement right away?

Yes, but... To do the purge your vCenter Server Service should be stopped.  Always better to this offline.  We typically do maintenance on our vCenter DB about every quarter.

View solution in original post

Reply
0 Kudos
6 Replies
Troy_Clavell
Immortal
Immortal
Jump to solution

performance of vCenter is more or less the result of a healthy non-fragmented database.  When was the last time you performed any SQL maintenance on the vCenter DB?  You'll probably want to reindex, purge and if you aren't already switch your recovery model to simple mode.

http://kb.vmware.com/kb/1025914

http://kb.vmware.com/kb/1003990

OsburnM
Hot Shot
Hot Shot
Jump to solution

Troy,

Thank you for your response & suggestions!  Very helpful.  I ran the SQL Scan for defragmentation per the KB suggestion.  To my knowledge we have never done this before (I guess I always assumed to was automatically defragmenting on a scheduled basis).

Below are the results-- if I understand the KB correctly, it appears tables STAT1 & STAT2 are very fragmented.  Does this look right to you?

DBCC SHOWCONTIG scanning 'VPX_HIST_STAT1' table...
Table: 'VPX_HIST_STAT1' (2002106173); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 348094
- Extents Scanned..............................: 47748
- Extent Switches..............................: 341079
- Avg. Pages per Extent........................: 7.3
- Scan Density [Best Count:Actual Count].......: 12.76% [43512:341080]
- Logical Scan Fragmentation ..................: 98.61%
- Extent Scan Fragmentation ...................: 11.80%
- Avg. Bytes Free per Page.....................: 3765.7
- Avg. Page Density (full).....................: 53.47%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC SHOWCONTIG scanning 'VPX_HIST_STAT2' table...
Table: 'VPX_HIST_STAT2' (2018106230); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 871894
- Extents Scanned..............................: 109289
- Extent Switches..............................: 465280
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 23.42% [108987:465281]
- Logical Scan Fragmentation ..................: 46.35%
- Extent Scan Fragmentation ...................: 6.01%
- Avg. Bytes Free per Page.....................: 1416.5
- Avg. Page Density (full).....................: 82.50%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC SHOWCONTIG scanning 'VPX_HIST_STAT3' table...
Table: 'VPX_HIST_STAT3' (2034106287); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 302861
- Extents Scanned..............................: 37861
- Extent Switches..............................: 37860
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.99% [37858:37861]
- Logical Scan Fragmentation ..................: 0.01%
- Extent Scan Fragmentation ...................: 4.55%
- Avg. Bytes Free per Page.....................: 11.1
- Avg. Page Density (full).....................: 99.86%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC SHOWCONTIG scanning 'VPX_HIST_STAT4' table...
Table: 'VPX_HIST_STAT4' (2050106344); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 202203
- Extents Scanned..............................: 25280
- Extent Switches..............................: 25279
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [25276:25280]
- Logical Scan Fragmentation ..................: 0.01%
- Extent Scan Fragmentation ...................: 2.67%
- Avg. Bytes Free per Page.....................: 11.1
- Avg. Page Density (full).....................: 99.86%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Reply
0 Kudos
OsburnM
Hot Shot
Hot Shot
Jump to solution

After running the defrag, it appears to have resulted in the following on the STATS1 & STATS2:

Defrag Results:
Pages Scanned Pages Moved Pages Removed
348094  187430  160662
840535  728460  143428

According to the KB, this seems to be a good thing.

Re-ran the fragmentation query and the 4 stats now show the Scan Density percentages high & Logical Scan Fragmentation low -- all good things (I think).

From here, should I run the Purge Old Data script from the other KB or should I expect to see performance improvement right away?

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

From here, should I run the Purge Old Data script from the other KB or  should I expect to see performance improvement right away?

Yes, but... To do the purge your vCenter Server Service should be stopped.  Always better to this offline.  We typically do maintenance on our vCenter DB about every quarter.

Reply
0 Kudos
OsburnM
Hot Shot
Hot Shot
Jump to solution

Thanks Troy.  Good to know on the frequency of the db maintenance.  Will add it to a quarterly schedule.

Thanks again for the help & guidance.  I'll report back after I schedule a downtime & purge.

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

i fixed some typos in my earlier reply, but you get the jist.  You have a pretty large environment, so quarterly maintenance should be very helpful.

Good Luck!

Reply
0 Kudos