I noticed at a few customer sites that the Performance tab of VirtualCenter was getting sluggish but never got the chance to really pinpoint the problem. A couple of days ago user “jterpstr” posted about this on the VMTN forum and it seems that the old rows aren’t deleted from the database for some reason. The table grows to an enormous amount of rows which causes some queries to become unresponsive or very very slow. For more info and a possible solution keep track of this topic om the forum. Thanks to the guys in this thread for pinpointing the problem and narrowing it down to a possible cause.
Grant Ballard says
I am fighting with this issue at this very moment. VMware tech support has had me update the Virtual Center Server to 2.0.2 Patch 2 but this didn’t help…still not getting performance data. I was then told to run the MSSQL purge script referenced in Knowledge Base Article 1000125. I ran the script and 2 hours later I am still not able to get performance data. Since it is starting to look like I might have to whack the current VCDB database…I am thinking it might be just as easy to go ahead and upgrade to VC2.5. What do you think Duncan?
Duncan Epping says
That’s a tough one, when upgrading there’s a big change the same issue re-appears. Wiping it clean will probably not solve the issue because the query that causes the problem still floats around. I would, as a last resort, install from scratch… just to be on the safe side, not having to re-install / clean the database again and again. But I would definitely wait to see what tech-support comes up with.
Grant Ballard says
Yeah…that is true. I guess I will just have to wait and see what shakes out.
Clint Eschberger says
This is something I have noticed in our environment. I have particularly noticed in on one VC that is more heavily populated than the others. For example…
One VC we have (version 2.02 latest patches) manages around 80 host and around 1400 guests. When you try to bring up performance data generally you get a time out 2 out of 3 times. The VC is not on a slow machine either, neither is the SQL database.
One one of our newer VC’s we have 80 host and only around 200 guests at the time and performance data is speedy. I will track as we ramp these farms up to see how the degradation ramps up. We should be up to ~1600 guests on this one with in the next few months.
Steffen Oezcan says
We also had timeouts after a couple of months running VC 2.0.x. Tech Support told me, that one reason could be, running VC in a VM together with a poor storage performance regarding I/O. Seemed to be likely, because our environment was growing and growing, and the more VMs we were running, the more perf stats timeouts we had. They told me to do the following 2 steps:
– (VI Client): Administration -> VirtualCenter Management Server Configuration -> Statistics -> System Resources -> Statistics collection thread limit: value changed to 16
– (VI Client): Administration -> VirtualCenter Management Server Configuration -> Timeout Settings -> Client Connection Timeout -> Normal Operations: value changed from 30 to 300
May this´ll help your customers, it did with us. After upgrading to VC 2.5, our performance statistics are waaaaaay faster!
Grant Ballard says
On the thread on this on the VMware Forums, I updated it with what tech support did yesterday when they were webex’d into my virtual center server….
http://communities.vmware.com/thread/124865?tstart=0&start=15
Still not working though…:(
Grant Ballard says
I made the tweaks that Steffen suggested in the VI Client and I am getting stats again.
Erwin Zoer says
I also made the changes that Steffen suggested through the VI client and am getting performance statistics for the hosts again.
I also wanted to mention that I had performance statistics problems with VM’s as well and have been able to resolve that through VMotioning the VM’s from one host to the other. For some reason, I seemed to have had an issue with resource pools on hosts and this caused the VM’s not to report performance statistics. By moving the VM to another host, it is essentially restarted and performance counters were reported back to VC again.