Long response times or no results returned when specifying historical collection time spans for some workspaces

For historical data collection in large data sets, the intervals that you set for refreshing historical workspaces, for data collection, and for data chunking can affect performance dramatically. For example, when you select a time span of many hours (for example, 24 hours) for a workspace where a large number (tens of thousands) of rows of data has been stored in the persistent data store, the resulting query can take 60 seconds or longer to complete. Also, the monitoring agent might use a high percentage of available CPU while the query is processed.

About this task

Apply one or more of the following solutions to mitigate this problem:

Procedure

Select Refresh Every in the View menu to access the submenu.
Select On Demand in the submenu. If you set a short interval instead (60 or fewer seconds) the monitoring agent processing required might not complete within the refresh interval, causing subsequent requests to be queued. The monitoring agent then works continuously to process the query. High CPU utilization continues until the user navigates to another workspace or closes the Tivoli® Enterprise Portal.

What to do next

Specify longer historical collection intervals of 30 minutes or 1 hour, instead of the 15-minute defaults, for the attribute groups that generate this problem. Longer historical collection intervals reduce the number of rows per hour stored in the persistent data store.
Consider not collecting historical data for attribute groups that you are experiencing this problem with. Collect other data that provides the perspective on system performance or activity that you require.
Modify the KFW_REPORT_TERM_BREAK_POINT parameter in the KFWENV file of the Tivoli Enterprise Portal Server, which is located in the $CandleHome$\CNPS path. This parameter controls how many hours of historical data (counting back from the present time) are to be retrieved from the persistent data store (short-term history) data sets. The default is 86400 seconds (24 hours). A shorter time setting creates smaller sets of data to be searched in the persistent data store by the Tivoli Enterprise Portal. Older data (data excluded by changing this parameter) can be accessed if you are populating historical data in the IBM® Tivoli Data Warehouse. Be aware that modifying the KFW_REPORT_TERM_BREAK_POINT parameter affects all applications that are using the Tivoli Enterprise Portal Server.
The Tivoli Enterprise Portal queries the IBM Tivoli Data Warehouse for data older than the value of KFW_REPORT_TERM_BREAK_POINT. Configure a one-hour warehousing interval to ensure that data is available in the IBM Tivoli Data Warehouse. A one-hour warehousing interval also improves performance of situations and real-time queries.