Upon upgrading a View 5.2 environment to Horizon 6.0, the previously functional events database in View Administrator became unusable after the upgrade. The first place that was examined was the SQL database server where the View Events database resides. Upon logging into the server, it was quickly observed that the CPU of the SQL server was pegged at 100%. After some time the CPU of the SQL server returned to normal. To confirm the suspicion that the events database issues was related to the pegged SQL CPU some testing was performed. While watching task manager on the SQL server, View Administrator was launched and navigated to Monitoring\Events. Upon attempting to view the Events, the CPU on the SQL server spiked dramatically. It was time to find out why.
A little digging into the background of the View Events Database in VMware View explains the table layout. There are a couple of notable tables:
- Event – Contains metadata and search optimization data for recent events
- Event_data – Contains data for recent events
- Event_historical – Contains data for older events
- Event_data_historic – Contains metadata and search optimization data for older events.
In the Events view with a functioning events database the text below is shown:
This article from the VMware KB formally explains that the UI in View Administrator defaults to a maximum of 2000 events to be viewed. It also includes the settings to change to increase this value. It notes that this maximum number of events is in place to ensure performance. The higher the number of events in the event and event_data tables, the more time and system resources required to fetch and display the records.
There is also a setting in View Administrator that allows us to configure how long to Show events in View Administrator. When Show events in View Administrator is set for 2 months, as shown below, events older than 2 months are moved to the historical tables in the database. The Classify events as new for option specifies how long view considers these events “new.” Environments that have a lot of events should keep these values low, to ensure View Administrator can pull back the events quickly.
Now, getting back to the original problem that this article was written to discuss. Looking at the Events Database under system health showed the following:
The following items were gleaned from this view 1) View Administrator can only see 2000 events for performance reasons 2) there were 89964 events in the recent tables and 3) there were over 2 million events that have been recorded since the initial deployment of the environment. It seemed time to create a new database. After reconfiguring View Administrator to point to the new database, the Events view started working again.
In retrospect, it may have made more sense to modify the Show events in View Administrator time down to a week, hopefully pushing many of those events into the historical tables. Either way, the problem was resolved. After a few days, the number of events recorded in the events database was a much more reasonable.
One thing to keep in mind during the upgrade is that each desktop disconnect from the connection server and reconnect to the connection server when the connection server is rebooted registers an event in the events database. Multiply that by however many hundreds of desktops are on that connection server, and by how many times each connection servers was rebooted – likely more than once. This generated a lot of events. Also, some composer issues that occurred not long before the upgrade registered quite a few events. The issue there was that the linked clone pools were not configured with Stop provisioning on error and continued to fail over and over again. The error, caused by the “The resource ‘182’ is in use” (covered in another article) generated thousands of events in the events database.
By creating this new DB, there was a dramatic reduction in the amount of events that View Administrator was trying to access. The problem View was having was that the tables storing current events was too large.