Users Guide

Best Practices: Performance and Monitors | Performance Monitoring
OMNM 6.5.3 User Guide 443
Table size
— Based on your monitor configuration how large will database tables get? Each
monitor has a series of dedicated performance tables that store the Detail, Hourly and Daily
performance metrics. The number of tables depends on the retention policy associated with
the monitor.
A single table stores the monitor’s detail data for a 24 hour period. Detail data are individual
performance metrics collected and/or calculated during each poll. After that initial 24 hours,
OpenManage Network Manager creates a new table to store the next 24 hours’ of detail data
and so on.
Because of the resulting table size, the number of performance metrics generated by a single
monitor in a 24 hour period impacts performance. Best practice is to configure each monitor
to produce less than 10 million rows per day. When monitors exceed that number noticeable
delays result when retrieving performance data. To determine the number of metrics retained
by monitors per day please refer to <# of metrics retained per day> calculation from the
previous section.
CAUTION:
These numbers depend entirely upon the system hardware, available memory and processor speed.
If a monitor does exceed the target maximum rows per day consider the following options singly or
in combination to change that:
• Reduce the number of retained attributes per poll.
• Reduce the polling frequency.
• Reduce the number of monitor targets per monitor. Notice that you can still have the same
number of targets if you split the targets among multiple monitors.
Finally, tune your database for the expected load. Refer to the
OpenManage Network Manager
Installation Guide for MySQL sizing recommendations.
Dashboard Performance Limits
Creating dashboards makes performance demands on your system. If you make too many, or
monitor too many attributes within your dashboards, system response times can suffer.
Performance can also suffer because you have too many dashboard portlets on a single page.
To work around these limitations, add another page (see
Portal Overview on page 122 for details),
then move some dashboard portlets from the over-populated page to the new one. You can also
split monitored attributes between different dashboards.
Monitoring from a Cloud Server
The following outlines hardware sizing for performance monitoring from a cloud server:
RAM Max Targets
(5 minute poll
intervals)
Heap Memory Settings Recommended CPU Cores
and Disk Space
16 GB RAM 10000 4 GB Synergy Web Server heap, 6
GB Application Server heap, 2GB
Database buffer
4+ core, 100 GB+ disk
space
32 GB RAM 25000 6 GB Synergy Web Server heap, 12
GB Application Server heap, 8 GB
Database buffer
4+ core, 200 GB+ disk
space