|This article provides an introduction to differences to running Domino on IBM i compared to Windows as well as provding general performance tuning tips for running Domino on IBM i
Table of Contents
Getting started with running Domino on IBM i? Here are some things you should be aware of when running Domino on IBM i
- On IBM i every Domino installation is a partitioned install. The Domino product code is always stored separately from the Domino server data. You will find the Domino product code located in the /QIBM/ProdData/Lotus/DominoXXX directory where XXX represents your release, for example /QIBM/ProdData/Lotus/Domino852.
- Domino on IBM i supports running multiple releases. For example, when planning your upgrade you could upgrade your test Domino partitioned server (dpar) to 8.5.2 while leaving your primary dpar at 8.5.1. For more information about multi-versioning refer to an old, but still relevant, IBM Redbooks publication Lotus Domino 6 Multi-Versioning Support on the IBM eServer iSeries Server.
- Domino installs and upgrades can be separate steps on IBM i. This means you can install the product during the business day and then upgrade the server at a later time. This will reduce the outage window required for the upgrade. The command then used to upgrade the server is UPDDOMSVR. For more information on the UPDDOMSVR command refer to UPDDOMSVR InfoCenter Topic.
- All Domino data must be owned by the QNOTES user profile for proper operation. This is particularly important for all objects in the Domino server data directory. To update the owner on an IFS file use the CHGOWN command, to update the owner of native objects use the CHGOBJOWN command.
- IBM i uses a different file locking mechanism than Windows. Thus, to prevent file access and data corruption issues, do not map a network drive to a Domino server's data directory while the server is active.
- For information on backup and recovery specific to IBM i refer to Backup and recovery strategies education modules available via IBM Support Assistant.
- Be aware of network changes or problems. Slow response in your network will cause delays and errors for your users. Also, Domino must have access to a functioning DNS server at all times in order to route mail. If the DNS server IP address changes in your environment you must also update the DNS server entry within IBM i using the CHGTCPDMN command.
When getting started analyzing system performance..
- Ensure the system you are using is designed to support your workload. To determine the minimum system requirements for your workload use the IBM Workload Estimator.
- To compare systems for Domino workload the system Mail and Calendar Users (MCU) rating must be used. CPW is for traditional workloads and should not be used for Domino, except in cases where the MCU rating is not available. To determine the MCU rating for your current system refer to Appendix D of the Performance Capabilities manuals.
- Version 5, Release 4
- Version 6, Release 1
- IBM i 7.1
Response time is the best indicator of system performance. The guidelines presented in this section are general guidelines limits where most customers start reporting a response time degradation in their environment. Since each system is unique the exact threshold where response time will be affected may be higher or lower depending on your hardware and system usage.
Level 2 cache is important for Domino performance. When comparing systems or planning for a new system you should be sure to include this in your considerations along with processing, memory, disk and network capabilities.
There are multiple tools available for collecting system performance.
A discussion on the details of these tools and how to use them is beyond the scope of this article. For an introduction on gathering performance statistics refer to Chapter 4 of the IBM Redbooks Domino 6 for iSeries Best Practices Guide.
- Keep CPU utilization at 85% or below for a single processor system
- Keep CPU utilization at 90% or below for a multi-processor system
- Be aware that a system can be CPU bound without showing a CPU utilization of 100%. How can this be? Imagine a system with 4 processors. If one processor is pegged, but other processors are idle, the overall system CPU utilization will be 25%. It is possible to have a single threaded, CPU intensive operation be running slowly and thus CPU bound without an obvious indication that CPU is the issue. You should review the CPU utilization for a single thread. If one thread is driving 100% of one processor or 25% overall CPU in our example, then your system is CPU constrained. Hint: Use the IBM Performance Tools for i5/OS WRKSYSACT command to see the CPU utilization at the thread level.
- By default all Domino jobs run with the same job priority, priority 20. There are cases when you may want to alter the priority of some tasks. One example would be to try and manage which jobs receive more CPU on a CPU constrained system. Changing the run priority can be done by following the instructions in the technote Changing the Priority of a Server Job Permanently on iSeries (IBM i). By changing the job priority you can or force intensive processes such as view index updates, agents or adminp to have lower priority over user interfacing tasks such as server and http.
- Machine pool faulting rate and paging rate should be at or below 5 faults and 10 pages per second.
- The memory pool for your Domino servers (the BASE pool by default) should stay at or below a Non-DB fault/pages rate of 100/300 per processor. So for 5 dpars running on a single logical partition or system with two full active processors should have enough memory to keep the number of non-db faults/pages per second of 200/600.
- Determining the correct amount of memory for a system can be challenging. One simple rule of thumb is to check your largest database and most complex views. You should have a minimum of 2 times the amount of space needed for the views in that application dedicated for the Domino server. For example, if you have an application database with multiple views that total 2GB in size you should have a minimum of 4GB dedicated to the Domino server in order for optimal memory performance during view updates.
- On a memory constrained system, until more memory can be purchased, reducing the size of the NSF buffer pool can improve performance. Be aware that reducing the NSF buffer pool may also reduce the number of router threads and you may need to manually increase the number to prevent mail routing slow downs. For information on how router allocates threads refer to technote 1093562.
- When reviewing disk I/O and percent busy rates you want to see the disks to be 35% or less busy.
- Avoid running out of disk! Ideally your drives should not be 90% or more utilized.
- The space used (%used) should be consistent across all drives.
- The protection/mirroring status should be active, not degraded as a status of degraded may indicate an under performing drive or possible disk and hardware errors.
There are things specific to Domino that can help or affect overall performance.
- Stay up to date on ODS level. It is not required that you update to ODS level 51 when you upgrade to Domino 8.5. However; there have been a number of performance improvements that will affect server performance and thus it is important to upgrade as soon as possible.
- Disable any unnecessary tasks. Are you running SMTP on your administration or hub servers? Are you running COLSRV400 on multiple dpars? Are you running DECS and not using it? Each and every task running under the Domino server takes some system resources to use so eliminating unnecessary tasks will improve overall system performance.
- Transaction logging has evolved to be a valuable resource for all customers. However; there is a performance impact to enabling transaction logs. In most implementations a CPU increase of 3% is seen, for example CPU used by the Domino server is 38% before transaction logging will be approximately 41% after. There is also typically an increase in the I/O rates between 5-15%. Thus if the percent busy rate of your disks is normally 10% busy you may see your drive %busy rate at 10.5 - 11.5% busy after transaction logging is enabled.