This topic outlines common causes for performance decreases and recommends usage of features and common maintenance tasks to improve the performance of your database.
There is a limit to the number of measures that can be written in an hour without overloading the system. This limit depends on the architecture, hardware resources, and database configuration, and not on a product limitation.
When the limit is reached you must remove non-essential measures or implement a second Performance Manager instance to reduce the number of measures.
The most common causes of performance issues are improper hardware, sub-optimal database setups, and insufficient database maintenance and monitoring. To optimize the performance of your database, ensure that the hardware is appropriate and your database is properly set-up and maintained. The following product areas should be checked in regards to performance:
Use the latest version as it contains the latest optimizations to queries that build the different views.
To enhance performance, Performance Manager caches measure objects in the systems RAM. When new results arrive the health data is calculated based on the cached objects instead of a database query, reducing the number of database calls required. Each time the Application Server is restarted this cache is lost and must be rebuilt when the Application Server starts. The cache is filled by querying the database, which means that during the rebuilding of the cache the database write times for measures will grow and results may be queued in the System Health page. The duration of the performance decrease is limited because once the cache is rebuilt the write time decreases and the results writing clears the queue.
Implementing storage reduction mechanism creates a data-delete job that physically deletes data from the database based on the configured settings. This job causes an increased workload on the database and therefore reduces overall performance. The data-deletion job is designed to pause to allow measure writing and therefore reduce the impact on measure write-times. The BackgroundDeleteIdlePercentage setting in the SVAppServerHomeConf.xml file specifies how long the data deletion process should pause in relation to the duration of the previous deletion command. For example, if the setting is set to 100, and a deletion packet took 200ms to complete, then the process will wait 200ms longer before it continues. We recommend to run the background deletion process only once a week, and to rebuild the indexes on the database afterwards.
Different views or pages in Performance Manager use different queries to collect the data to build the view or page. Views and pages can be based on different periods of time, and some views and pages require less data to be read from the database than others. In some views and pages you can reduce the returned amount of data by collapsing unneeded sections.
Although there is no logical limit to the amount of measures or monitors in a project, bigger numbers result in more data being read from the database, therefore increasing the time required to build a view. We recommend that you distribute the measures and monitors over projects, because results are written on a round-robin basis, where each project gets equal amount of time for writing the results.
When you delete a monitor from a project, a data-deletion task is spawned, which deletes all information related to the monitor, and re-aggregation takes place. When you delete a single monitor instead of the entire project, the project-wide health cache is continuously re-aggregated and could result in a performance decrease. We recommend that you delete the entire project wherever possible.
In order to prevent performance decreases, regularly perform the following maintenance tasks: