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

A data query can take longer than 60 seconds to complete if a time span of several hours is set for a workspace and thousands of rows of data are stored in the persistent data store. The monitoring agent might use a high percentage of processor capability while the query is processing.

About this task

Although historical data is still available to you, using longer collection intervals (for example, 1 hour) reduces the number of rows per hour that is stored in the persistent data store.

Procedure

  1. For the problematic attribute groups, specify longer historical collection intervals than the 15-minute default collection intervals, for example, 30 minutes or 1 hour.
    This reduces the number of rows per hour that are stored in the persistent data store while still making historical data available to your users.
  2. Only collect historical data for attribute groups that you are interested in.
    This eliminates unnecessary collection, which reduces processing time used by the monitoring agent and also reduces the amount of storage that the persistent data store needs.
  3. Modify the KFW_REPORT_TERM_BREAK_POINT parameter in the Tivoli Enterprise Portal ENV file.
    The KFW_REPORT_TERM_BREAK_POINT parameter controls how many hours of previously collected historical data are to be retrieved from the persistent data store Short Term History data sets. The default is 86400 seconds or 24 hours. Reducing this value shortens the search of the persistent data store by the Tivoli Enterprise Portal.
  4. Older data can be accessed if you populate historical data in the Tivoli Data Warehouse. Configure a one-hour warehousing interval to ensure that data is available in the Tivoli Data Warehouse.
    The Tivoli Enterprise Portal queries the Tivoli Data Warehouse for data that is older than the value of KFW_REPORT_TERM_BREAK_POINT. A one-hour warehousing interval improves the performance of situations and real-time queries.
  5. When you select a historical time span, set the refresh interval to on demand instead of displaying a historical workspace with a 60-second interval.
    The monitoring agent processing that is required to complete the request might not complete within the 60-second refresh interval, which might cause subsequent requests to be queued. Then, the monitoring agent continuously processes the query and sustains the high processor usage until you go to another workspace or close the Tivoli® Enterprise Portal.