VMware Cloud Community
bopp
Contributor
Contributor

Performance stats not available

If I go in to view performance stats for a host or VM in VC2 it just comes up with "Performance data is currently not available for this entity".

In VC1 it used to log the data and display it fine.

Any ideas?

0 Kudos
22 Replies
biekee
Hot Shot
Hot Shot

I have had this issue once, it turned out that the correct time was not in place. So you should check the time on your vc and on the esx servers, they should be in sink.

see if that helps,

bk

0 Kudos
bopp
Contributor
Contributor

Thanks for the suggestion. Time was out of sync on one ESX3 server due to the problem with enabling NTP with VC2. I have fixed this so it is in sync now but it still reports the same error.

Any other ideas?

0 Kudos
jstoltz_w
Contributor
Contributor

Same problem here even with time in sync on all the machines. This thread is the same issue:

http://www.vmware.com/community/thread.jspa?threadID=45765&tstart=0

0 Kudos
bopp
Contributor
Contributor

Hello

Sorry I hadn't seen that one thread. Hopefully someone from VMWare will put their hand up and provide a solution.

0 Kudos
bopp
Contributor
Contributor

I have fixed it myself.

If you stop the Virtualcenter service and then empty the VPX_HIST_STAT & VPX_SAMPLE tables then restart Virtualcenter it will correctly record and display statistics.

Unfortunately any historic statistics are gone, but at least they are working and it doesn't require a fresh install.

0 Kudos
Mike_Fink
Enthusiast
Enthusiast

Sorry, I am not a SQL admin, so this is not my normal stomping ground (SQL Enterprise Manager).

How do I empty those tables? I am assuming its a script?

Thx!

0 Kudos
Mike_Fink
Enthusiast
Enthusiast

I figured it out, but I thought I would post it up here in case others needed it:

From the SQL query analyzer run:

delete VPX_HIST_STAT

and then the same command with the other table name.

Make sure the VC service is stopped; then restart VC. You should then be able to see your preformance data.

Thx for the help!

0 Kudos
Jae_Ellers
Virtuoso
Virtuoso

In my test farm the tables are preceded with vc., so the table names are vc.VPX_HIST_STAT and vc.VPX_SAMPLE

-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://blog.mr-vm.com http://www.vmprofessional.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-
0 Kudos
bopp
Contributor
Contributor

Another point is that sometimes it misses recording statistics.

Go into Administration>Server Settings and set "Statistics collection thread limit" to something like 10.

This probably depends on how many servers/vm's are running.

0 Kudos
eyezlee
Contributor
Contributor

I tried the suggestion of deleting the info in in the tables and the graphs still did not work. I ended up doing a repair install of VC which refreshed the DB and now my graphs are performing as expected.

0 Kudos
stuten
Enthusiast
Enthusiast

I just got bit by this during a VC upgrade (the stats not showing). Interesting that the "upgrade" sat at a stage that showed it was migrating peformance data, and if you look in the DB it is there (nice).

I also noticed that my custom attributes I had defined and had in VC 1.2 were left behind too Smiley Sad

Doesn't seem like much of an "upgrade". I believe I'd suggest a clean install. I believe I'll give tech support a call and see what they say about the upgrade losing performance data. If I find anything out I'll post it here.

Message was edited by:

stuten

As info there is a KB article about this now. It did fix my reporting of new data, but old data is still hosed.

http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&docType=kc&externalId=6579181&sliceId=SAL_Public... 0 483287&doctag=Author, KB Article

0 Kudos
ccullingford
VMware Employee
VMware Employee

I was experiencing this same problem.

We are running VC 2.0.1 with an oracle back end. I verified the date \ time on each host and it was current. I then emptied the VPX_HIST_STAT & VPX_SAMPLE tables then restarted Virtualcenter. This seemed to fix the problem at that time. I was able to get performance stats from the host and the VMs.

I noticed today (about 2 weeks later) that I am experiencing the same problem. Any time I click on the performance tab I get an error stating "timed out waiting for the server response". Where the graph should be it says "performance data is currently not available for this entity"

I again verified the date \ time on the host and it was correct as was the time on the VC server.

Does anyone have any thoughts / ideas?

Chris

0 Kudos
hicksj
Virtuoso
Virtuoso

Figured this out this morning.

Periodically have a VM that won't properly report... Other VM's in the cluster and on the same host may be reporting fine, but for some unknown reason a few of VM's will not.

I found after this happens, click on another VM that is properly reporting, then go back to the performance tab of the non-reporting VM. You'll now have the "Change Chart Options..." hotlink available (but no graph showing). Go into the options elect a different chart option, i.e. the Memory or Disk usage. Click ok.

That graph will load. Then you can go back into the chart options and select CPU. The data will now show.

At least, that's what worked for me. Just tested it out again and it worked. Obviously this is sub-optimal, but its something! Smiley Happy

0 Kudos
ccullingford
VMware Employee
VMware Employee

Thanks for the post but I am not getting any performance graphs. I checked all of my host and about 20 or so of my VMs and I get the same error on all.

Chris

0 Kudos
mstahl75
Virtuoso
Virtuoso

Every once in a while we will get that with some VMs. I think it is all related to the stat rollups that happen for the database. Too many fields in the database that end up making the VIC think things have timed out when it is really still just waiting on the query to complete.

I know for the most part that the procedure from above, going to another VM and then back, allows data to be retrieved in our setting.

0 Kudos
shahboy
Contributor
Contributor

I found the problem was because someone (Probably me!) unchecked the objects under realtime for the CPU. It was stupid but a simple fix. I spent about 1 hour trying to figure out why I couldn't get the performance graph to work right.

0 Kudos
Goatie
Enthusiast
Enthusiast

I've had the same issue, but it seems to have come about when we changed daylight savings time periods. Since that point I could not view current or historical graphs.

After reading this thread I went into VC -> administration menu -> config -> statistics

I set the threads to 10 and changed the logging level from 1 to 4.

I went back to a host and opened the perf tab and data displayed, including data prior to the change.

Cheers!

0 Kudos
patk
Contributor
Contributor

I've had similar problems like everyone else and started a decent thread:

http://www.vmware.com/community/message.jspa?messageID=675107#675107

I think this performance stats problem has multiple dimensions to it. Setting up maintenance for the SQL transaction logs, and defragging the table indexes daily helped. If you are missing data make sure your transaction logs aren't 8 times the size of your VC database. Overall, network latency/bandwidth does play a large role as well. One of the best ways to see if this is a database or network issue is to connect to the ESX host directly using the VI client and view the perf data that way. If the data comes up right away then its either a time sync issue or a DB problem.

0 Kudos
Erwin_Zoer
Contributor
Contributor

Like most of you I encountered the same problem and tried all steps described in the various KB articles and community posts. However, nothing helped. I then digged a little deeper and found that my hosts would not collect CPU and memory statistics for the affected VM's. I determined this by connecting to the hosts directly using the VI client and looking at the performance tab for the affected VM's. Disk, network and system performance counters were there but not CPU and memory statistics. It then occurred to me that the problem may have been related to a resource pool problem I noticed on a host some time earlier. All VM's affected were part of the problematic resource pool and most of them still located on the host which had problems.

In order to resolve the problem, I VMotioned each problem machine from the host on which it had problems to another host and this resolved the issue.

Hope this is helpful for others too.

Erwin

0 Kudos