 | [back to "Optimizing server performance: Domino clusters (Part 1)"]
Cluster performance results, from-the-field (sidebar)
The following sections show the Domino statistics that we gathered on the clustered servers. The statistics show a performance problem on Server 1. Server 1 was the first server installed, which resulted in larger mail files. In addition, Server 1 has the most sophisticated users (who send larger mail messages, create more calendar entries, and so on). In fact, Server 1 has twice the activity of Server 2. This then affects the performance on Server 3, which is the failover server for both Servers 1 and 2. The final outcome is that Server 1 experiences serious bottlenecks with cluster replication.
Server 1: Load statistics
The mail, database cache, and database buffer pool statistics all indicate that this server has the maximum number of users that it can support (1450 users). The following statistics show the high mail activity on Server 1.
- Mail.TotalKBTransferred = 409338
- Mail.TotalRouted = 46031
- Mail.Transferred = 12173
The following statistics show the database cache level on Server 1. The DbCache is a table of databases in cache memory. Notice that the database cache peaked out at well over 723 maximum entries, and reached the "high water mark" of 1084 -- the hard limit of Domino R4.x. (R5 allows a much larger DbCache.)
- Database.DbCache.CurrentEntries = 754
- Database.DbCache.HighWaterMark = 1084
- Database.DbCache.MaxEntries = 723
- Database.DbCache.OvercrowdingRejections = 3764
The following statistics show the database buffer pool level on Server 1. The database buffer pool is a cache of 300k per database in the DbCache for view pointers, and so on. You can expect the database buffer pool to reach limits in environments with RAM levels of 1GB or less.
- Database.BufferPool.Maximum = 247692522
- Database.BufferPool.Peak = 244166400
Finally, we looked at the following statistics that show the transaction and user peak levels on Server 1.
- Server.Trans.PerMinute = 1231
- Server.Trans.PerMinute.Peak = 14308
- Server.Users.Peak = 617
Next, let's look at how the heavy load on Server 1 affects the performance on Server 3, the failover server.
Server 3: Load statistics
Remember that in the clustered configuration, both Servers 1 and 2 failover to Server 3. So, Server 3 has more than 2600 mail files. Meanwhile, Server 1 has the heaviest load and its users' mail files often need to failover to Server 3. The following statistics show the database levels on Server 3, which indicate serious performance degradation.
- Database.BufferPool.Maximum = 184183296
- Database.BufferPool.Peak = 185068800
- Database.DbCache.CurrentEntries = 1072
- Database.DbCache.HighWaterMark = 1084
- Database.DbCache.MaxEntries = 723
- Database.DbCache.OvercrowdingRejections = 21321
Server 1: Clustering statistics
With cluster replication and view indexing, the load on Server 3 backs up the cluster replication on Server 1. Server 2 does not send as much data as Server 1, so the cluster replication can continue with no noticeable performance hit. However, Server 1 experiences serious bottlenecks with cluster replication. The following statistics reveal the clustering bottleneck on Server 1:
- Replica.Cluster.SecondsOnQueue.Avg = 1565 (that is, it takes almost 30 minutes for requests to be fulfilled)
- Replica.Cluster.SecondsOnQueue.Max = 5505
- Replica.Cluster.WorkQueueDepth.Avg = 280 (that is, 280 sends are pending)
- Replica.Cluster.WorkQueueDepth.Max = 704
- Replica.Docs.Added = 25594
- Replica.Docs.Deleted = 27038
- Replica.Docs.Updated = 1437
- Replica.Failed = 4826 (not good)
- Replica.Successful = 19682
|