In a recent post, I explained the essential role that your database job scheduler (e.g., SQL Server Agent) plays in keeping the vCenter (VirtualCenter) database size under control. The statistics level is another critical factor that affects your database storage and performance requirements.
The statistics levels are easily — perhaps too easily — configured by using the VI Client:
You can read in more depth about the performance statistics in the Basic System Administration manual and the VirtualCenter Monitoring and Performance Statistics Tech Note, which has this to say about stats level selection:
Level 1 has very low overhead on both the VirtualCenter server as well as the ESX Server hosts. Levels 2 – 4 have slightly greater overhead on ESX, but can adversely impact VirtualCenter performance if there are more than 10 ESX Server hosts. In particular Level 4 can quickly fill the VirtualCenter database, so it should only be turned on for limited periods of time.
When it says Level 4 can quickly fill the VirtualCenter database, that’s not hyperbole. Take a look at this chart to see what happens when the “5 minute” interval is changed from level 1 to level 4:
The VPX_HIST_STAT1 table — the one that corresponds with the “5 minute” interval — immediately begins consuming many times its previous size. After a day, the number of rows in that table increased about 20 times! (The tick marks across the x-axis of this chart each represent an hour.)
Recovery is simple, but not immediate. After resetting to level 1, the additional rows disappear through attrition as the rollup process does its job.
The statistics levels are configurable in order to collect more detailed performance data on your VMware infrastructure. As with most things, there is a tradeoff — making it critical for administrators to know that a seemingly simple change via the UI can put a huge hit on your database — not only in storage requirements but performance, too. Do yourself a favor and talk to your DBA before changing your vCenter Server performance stats levels.
Pingback: VMware vCenter Server 4 task and event retention | VCritical
Pingback: vCenter 4.1 Database Recovery Model Defaults | vNinja.net
It’s Absolutely best practices to manage statistics – pingback from http://communities.vmware.com/blogs/esxiting
Great post!
Henrik