Table of Contents
Having a set of historical baseline data gives Administrators a reference point to measure against when changes are made to the environment. Establishing the baseline also gives Administrators an opportunity to identify obvious performance bottlenecks or trends. For example, the CPU may reach peak levels every Monday morning or disk queue lengths may exceed normal operating boundaries during the same periods each week.
To help capture accurate baseline historical data, follow this set of best practices:
- Capture a complete view of the infrastructure’s performance: Kernel statistics (such as CPU, memory and disk utilization).
- Periodically capture the information to get long term trend analysis. Do not rely just on a quick snapshot of a system before a tuning event take place.
- It should be representative of normal system loads. Do not record or take inconsideration of data taken during extra-ordinary events (periods of unusually quiet activity, such as the New Year holiday period).
- Do not include data from periods with unusual events (such as system failures or high usage volumes).
- Record at a set period of time (For example, at least once a week, and preferably at least once a month).
- Include descriptions of what components or services were running on individual servers (ServerTasks, Backup or Anti-virus facilities) at the time of capturing the data.
After every major tuning changes or system upgrades (when the system is stabilized), take a new set of baseline statistics.
The following metrics provide a basis for establishing baseline statistics. With experience, you will find other metrics useful or more applicable for the type of tuning performed.
- Memory.Available MBytes
- Processor.% Processor Time
- LogicalDisk Avg. Disk Seconds Read
- LogicalDisk Avg. Disk Seconds Write
- LogicalDisk.Avg. Queue Length.
- o/s drive
- tx log
- view rebuild temp. drive
Events4 / Statrep
Note. The Replica.Cluster statistics are only relevant if the server being monitored is a member of a Domino cluster. They give an indication of the ability of the cluster to maintain synchronized replicas.
For a comprehensive guide to Domino statistics and their definition, read Lotus Domino Statistics.
Collecting Domino Statistics
Administrators can use the COLLECT and EVENT server tasks to monitor and collect server statistics in entire Domino domains. The procedure is well documented in the Statistics and the Domino System
, IBM Lotus Domino and Notes InfoCenter article. The sample interval should be no lower than 15 minutes, although Administrators may find 1 hour suitable.
Statistic collection can be performed on any Domino server. A best practice is to configure statistic collection on an Administration server and remotely collect statistics from other servers.
Figure 1 shows an example of a customized Monitoring Reporting database (STATREP.NSF). It contains a document for each sample according to the frequency set in the events4.nsf, statistics profile. Add or remove columns, and choose from all available statistics. These statistics can easily be exported as a comma separate volume file, so graphs can be produced.
Figure 1: Monitoring results in statrep.nsf