Considerations for improving the performance of Domino servers

Considerations for improving the performance of Domino servers-Linux Enterprise applications-Linux Server Applications. (1) Understand your configuration

The Domino administrator should know the supported server configurations. The main components of any server include memory, CPU, disk (including logical and physical), and other components such as online buffer memory and the number of disk controllers. The following are some additional considerations to avoid configuration problems:

1) Use a disk as fast as possible (for example, 10,000 RPMs ).

2) use hardware RAID on software RAID, which is faster and can reduce the CPU load.

3) A sufficient disk sub-system can reduce memory requirements because a small amount of temporary I/O is used for memory usage.

4) for the Windows NT platform, disk fragmentation can fully improve performance. We recommend that you clear disk fragments once a week.

5) Ensure that the server has at least 4 MB of memory available (10 to 20 mb better) even at the maximum load ). It should be noted that the Cache Policy of the platform may impede the operation.

6) standard server configurations are not necessarily optimal for Domino servers. The important thing is sufficient disks and controllers. You can use the NotesBench benchmark data of the hardware vendor as a guide.

(2) Allocating I/O through physical disks

Generally, physical and logical disk structures are system resources that people often ignore and are the most frequently overloaded. The best way to improve performance on many Domino servers is to allocate I/O through different physical disks. Ideally, put the following I/O-related files on different physical disks:

1) page files on different platforms

2) Your NSF File

3) Domino R5 transaction log

It is best if you can place them on different controllers. This method improves I/O throughput by distributing loads on the bus, controller, port, and disk. Therefore, it is best to use a few small disks instead of a large disk. In particular, the more you isolate R5 transaction logs from other disk activities, the better your server performance will be. Note: For some systems such AS/400, the operating system can automatically optimize data distribution between available disks and controllers.

(3) log performance data frequently

If you do not make a log of performance metric data, you cannot determine whether your adjustment is successful or failed. If you log frequently, you not only have a better understanding of what you do, but also provide detailed documentation for additional expenses. You need to measure the data from the operating system and Domino. The following are major metrics (based on the platform ):

1) all CPU usage (expressed in percentages ). If the value is greater than 70% or 80%, a red sign is displayed on many platforms, such as Windows NT.

2) available memory or usage. Remember, when the available memory is less than 4 MB, the cache needs to be reduced.

3) disk sequence length (usually less than 2 items in the sequence) and average disk service time (for NT, it should be less than 70% ).

4) page file size and usage. Usage should be lower locally, or it is worth evaluating the usage and efficiency of your disk subsystem. For example, for the Domino Mail Server on the NT platform, the page usage should generally be less than 150 pages/second.

5) Domino statistics and events on mail throughput, replication, Web server activity, and database activity.

6) Domino logs (log. nsf) are cumbersome but useful (note that logs are enabled only when necessary because they affect server performance ). Note that data is often collected and analyzed. It is necessary to capture performance data before or after major configuration changes.

(4) Optimize Domino　

Domino R5 does a lot of work in automatic configuration and dynamic reconfiguration of key parameters to achieve maximum performance. The following are some suggestions on how to optimize the Domino R5 server itself:

1) set the number of mailboxes correctly. Multiple mail. box files can reduce competition for mail. box files during email-related activities. When you add the second mail. box, the performance can be greatly improved. Experience is that we use a mail. box to support 1 ~ 200 users, two or more mail. box support 200 ~ 1000 users, up to 10 mail. Boxes support more than 1000 users.

2) For non-partitioned systems, let Domino dynamically set the NSF_Buffer_Pool_Size variable. This is especially important for low-memory server configurations. A large buffer will impede core memory management.

3) for the partition system, you need to allocate NSF_Buffer_Pool_Size, because Domino cannot automatically determine the actual available memory in each partition. The recommended formula is: (system memory/number of partitions)/4.

4) based on the available memory, let Domino allocate the mail transmission thread as needed (for local transmission ).

5) Assign the mail transmission thread to the Domino router as needed (to be sent to other servers ).

6) Use R5 transaction logs. It provides you with a large amount of complete data, allowing the server to quickly start up and improve performance by 10% ~ 20%. Properly configure a Domino R5 server to run on a mid-range Windows NT machine. 20,000 messages can be transmitted per minute (each message has an average of 10 KB )!

(5) Use NotesBench benchmark data

Many benchmarks only tell your sellers what they want you to know, but the NotesBench benchmark is different. The NotesBench benchmark data allows you to make a detailed comparison of the Domino capacity on different hardware configurations of different vendors. You can even use this data to estimate the total cost. Carefully reading NotesBench data and detailed reports obtained from it is a very good way to collect information. You can optimize your system configurations. Checks the disk structures, kernel settings, patches, and other resources used (or unused) by experts to obtain the maximum performance parameters from their systems.

(6) Signal Analysis

A signal is a communication mechanism used to process threads. Essentially, a signal uses a handshake mechanism to determine the use of resources. When the server is overloaded, the Administrator may receive a signal from the console. The following are some common signals obtained by observing Domino 4.6 and explains what they mean in terms of performance:

1) Collection (0x30B) and Collection Queue (0x309). This implies that the CPU and memory have reached the bottleneck. The best solution is to extend the management process activity to idle time and optimize the I/O subsystem.

2) DB (0x245) and DB Queue (0x244): This implies that the database cache and disk I/O have reached the bottleneck. The best solution is to increase more memory and optimize the I/O system. Enabling domain-level replication is also helpful.

3) BTree (0x255): it implies how to store views and refresh view indexes. The best solution is to extend the refresh View index to idle time and optimize the I/O subsystem.

(7) Understanding the symptoms of server overload during use

A typical problem for the server is slow speed or mail transmission failure, which prolongs the user's response time and the time for searching for mail addresses. To check the mail Transmission, you can view the percentage of your disk usage time and the length of the mail sequence. For R5, you can also check the number of mail. box files and the number of local mail Transmission threads. To improve the response time, We should optimize the distribution of I/O-related files in the disk subsystem as much as possible. If the address search is slow, users can use simple directories on their own clients, which reduces the load on servers and networks. You can also check the click rate of Name Lookup Cache. A good click rate should be 85%. If the problem is slow page refreshing rate or non-responding Web server, check the number of HTTP threads and the percentage of disk usage time. Set the number of HTTP threads to (one thread is used for every 10 users ). How can I determine if a server is not fully used? For NT, the index is that the CPU usage is lower than 50%, the disk swap rate is lower than 50%, or there are often more than MB of available memory. However, note that the resource required by the newly added user may not be equal to the average resource of your current user. For example, as the number of users increases, each user's memory needs will be reduced because the fixed memory is allocated to more users.

(8) consider clustering

Clusters are the main feature of Domino Enterprise Servers. The cluster helps you achieve dynamic load balancing and automatically optimize resource usage in the cluster. In the cluster, you can also transfer email and application failures, including Web applications. You can set R4 and R5 servers on any platform supported by Domino in a group, or cluster partition servers with unpartitioned servers. The Domino cluster is the best way to increase the robustness and reliability of server resources. It is also the safest way to add R5 servers to the R4 cluster. Based on your platform, a low-price system cluster can provide higher reliability than a single huge server at a lower initial cost. In addition, the cluster greatly reduces the number of users who fail to connect to the server. For example, on Windows NT platform, we recommend that you use a cluster if there are more than 750 active users in a system.

(9) Consider partitioning

Partitioning improves resource usage and reliability of high-end Domino systems, and allows you to distribute servers by department or function while maintaining the benefits of consolidation. Some organizations even use partitions to create "service-level options" (that is, place some important managers in one partition and others in another partition ). Generally, the number of partitions in the system should not exceed the number of CPUs. The AS/400 system is an exception and is suitable for partitioning. The AS/400 platform also logically isolates partitions, so even if one partition is broken, other partitions can still work normally.

(10) Know when to join and when to distribute

Unless you have a convincing reason, you can choose to join on the distribution as a growth strategy. Federation always reduces costs and improves reliability: fewer servers mean less complex server topology, less activity between servers, less network flow, less replication, and less email transmission between servers. When Will distribution servers be selected instead of combining them? You may have geographic distribution requirements. Local servers process local users and data at a low cost. Or you start to expand relatively small, but the growth is very fast, so add more servers to accommodate new users, or to make better use of the current investment.

You can also set the accounting task to optimize the performance of the Domino System: (To put it bluntly, edit notes. ini)

1. Change the frequency of adding records to the Message Queue. By default, Domino creates records every 15 minutes. During peak usage, if the system performance is reduced or the system virtual memory is insufficient, the frequency of adding records to the Message Queue should be reduced. To modify this setting, add BillingSuppressTime = minutes in the NOTES. ini file (15 by default)

2. Control the running of a Billing task to send records from the message queue to the accounting database or file. By default, a Billing task runs every minute for 10 seconds. When the system is busy, you can change the time and frequency of running the Billing task. To modify the Running frequency of a Billing task, you can add BillingAddinWakeup = seconds (60 by default) to the NOTES. ini file to modify the running duration of the Billing task.