This summary of tuning tips for Domino 6 on z/OS is derived from IBM Redbooks publication SG24-6904.
Following are summaries of tuning tips given in IBM Redbook SG24-6904 covering z/OS, disk I/O, network, and Domino subsystem areas.
Key recommendations for tuning z/OS to run Domino:
Make sure you have enough central memory for Domino.
Domino creates multiple address spaces, some of which have large working sets. z/OS UNIX System Services also makes extensive use of storage for performance in the kernel address space, DFSMS dataspaces, and zFS colony address spaces. You need enough real storage on your processor for these--otherwise, you'll page to DASD, which will severely impact Domino response times.
In the BPXPRMxx member in SYS1.PARMLIB, check your z/OS UNIX System Services settings and make them large enough.
There are several z/OS UNIX System Services parameters in BPXPRMxx which, if too low, will cause problems in the Domino server; the server may not be able to create new tasks or get the virtual storage it requires. Refer to Domino 6 for z/OS Install Guide for the recommended values and follow them. That documentation ships with the product and is also available at: http://www.lotus.com/ldd/
From the navigator window, select Documentation Library -> by product -> Domino for z/OS -> 6.0. You can download the install guide from there.
Make the Domino server a high-priority z/OS workload.
The Domino server is an online system. It needs the same level of service that you would give to your production CICS or IMS systems. If the priority within z/OS is not set high enough, then response times to clients will suffer and client requests will time out.
Tune and monitor the entire z/OS system.
If you add a Domino server to a badly-tuned z/OS system, it will suffer--so do all the things you would normally do for performance. If you need the additional expertise, ask IBM to help set up the system before you install the Domino server. Then, as you start to use Domino, monitor the system closely to see how Domino performs.
Check out the z/OS UNIX System Services performance tuning tips.
These are available at:
You can also read the IBM Redbook Debugging UNIX System Services, Lotus Domino, Novell Network Services, and other Applications on z/OS, SG24-5613.
Note: Use the new Domino 6 for z/OS command, dom_verify_os , to verify your BPX parameter values. For more information, see 5.2, "Verifying BPX parameters after Domino installation", of redbook SG24-6904.
Key I/O tuning recommendations:
We recommend using zFS instead of DFSMS in critical file systems used by Domino.
We recommend using z/OS V1R3 or above to get the latest enhancements in zFS.
Monitor the system.
Look for high channel utilization. Watch for DASD devices with high activity that are not performing well.
Use zFS where possible.
If not using zFS, carefully follow the recommendations in Chapter 3 of redbook SG24-6904. Use the D GRS,C command to check for latch contention. Monitor HFS datasets for a need to reorganize the data.
Use high performance DASD subsystems such as the IBM ESS.
This has the additional benefit of allowing you to use Parallel Access Volumes to improve the DASD performance.
Consider the performance implications of allowing users to index Domino databases.
Key network tuning recommendations:
Consider the whole network.
The network consists of many hardware boxes and links. Monitor all components in the network and address bottlenecks.
Define REGION=0M for the TCP/IP region size.
TCP/IP development recommends setting the region size at 0. TCP/IP buffers are dynamically allocated in the private area. REGION=0M allows TCP/IP to allocate the maximum virtual storage above and below the 16 MB line. If you have implemented an IEFUSI exit, check that it will allow the specification of 0M for the region size.
If you use the sample TCP/IP start procedure available in the SEZAINST sample library, you will find that releases prior to V2R8 include a sample procedure with a region size of 7500 KB. Ignore this setting and use 0 instead. Consult INFOAPARS II11710, II11711, and II11712 for this and other tuning information.
Key recommendations for tuning Domino 6 for z/OS:
Do not change the following parameters in Domino 6 for z/OS:
Leave the values at their defaults. Otherwise, you may cause problems with the Domino server on z/OS.
Note: In Domino 6 for z/OS, the default value of Server_Max_Concurrent_Trans is -1, which is the disabled setting. Do not change this default value.
Do not run unnecessary Domino server tasks.
Don't start any server tasks that you don't need. Check the ServerTasks and ServerTasksAthour variables in notes.ini, and remove any addin tasks that are not required. Also check your server configuration document, particularly the NOTES.INI Settings tab, for unnecessary tasks. For example, you may not need tasks such as logging and billing. See the Domino 6 Administrator help database for a more detailed description of the ServerTask and ServerTaskAthour ini variables, as well as information about the configuration settings document.
Note also that in some cases, there are advantages to running multiple copies of an addin task, such as Update or the cluster replicator to increase throughput and shorten various processing times. If you use multiple instances of these addin server tasks, be sure it is necessary to do so.
Schedule tasks for non-peak times.
Some tasks run on a scheduled basis. Schedule them to run at non-peak times. Examples are compact, index (to create a new full text index), update, updall, and fixup. The schedule is set by the Notes administrator, but should be agreed to by the z/OS operations staff to ensure that it does not interfere with other peak workloads, administration tasks on the server, or system and Domino backups.
Balance work between the server and the clients.
Lotus Notes is a client-server application. It runs on a combination of the Domino server and the Notes client. (If you are using a Web browser as the client, the work that can be done on that client is limited.) Consider running some functions on the client rather than on the server, to minimize the server load. For example, you could tell your users to:
– Put all users that they send mail to in their local Domino Directory, to avoid searching the Domino Directory on the server when sending mail.
– Replicate their mail and other databases to their Notes client, to offload processing from the server.
As you consider these ideas, keep in mind how much server offload you might get. For example, you may not be doing your mail on the server (no load), but you do need to replicate with the server (a load). Also consider the management aspects of users having database replicas on their workstations.
Educate users on replication.
If users replicate databases to their Notes clients, educate them on the replication interval. We recommend a value of 15 to 30 minutes or more. As each replication uses server resource, even if there is no data to transfer, and a longer interval will reduce the server load.
Also educate users to use scheduled replication only on databases for which it makes sense. Within IBM we recommend that some applications be run locally by replicating them to the client. However, for applications used infrequently (for example, to submit expense claims), we recommend that those databases do not replicate automatically. Instead, the application reminds the user to replicate the database manually whenever they update information in the local replica.
Recommendations for initial sizing and ongoing capacity planning:
Initial estimates of the resources required to support a Domino server are based on estimates of various factors, including:
– Number of registered users
– Number of connected users
– Transaction rate generated by the users
– Average CPU time used per transaction
– Amount of data you will have, including the amount of data an average user will have in their mail file. The more accurately you estimate these values, the more accurate your estimate of resource needs will be.
Make use of the capacity planning assistance available.
For more information, see 8.8, “Capacity planning assistance” in redbook SG24-6904.
Base your capacity planning on your own measurements as soon as possible.
Every Domino environment is different. Therefore, you should monitor your system as soon as you have a significant Domino workload, and then revise your plans based on that. If you have other Domino servers, you can collect information on your workload profile from them and use that to help validate your assumptions.
If you will have more than 5,000 Notes client or POP3 registered users, 700 IMAP registered users, or 1,500 iNotes client registered users, consider using Domino server partitioning.
For more information, see 8.4, “The use of Domino partitioned servers” in redbook SG24-6904.
Remember that these guidelines may change.
These guidelines were put together in November 1999 for Domino Release 5.0, OS/390 Version 2 Release 6, and 9672 generation 6 processors--and modified in November 2000 to reflect changes. We have seen a significant increase in capacity with Domino 6 for z/OS, and with the reduction in the number of DPARs made possible with release 6.
Beware of running your own performance tests and misinterpreting the results.
It is possible to set up some seemingly simple performance tests. However, we have seen very misleading results when trying to use the run time of a single Domino function to
estimate the performance of a production workload. Unless you understand exactly which system resources the function uses, and can accurately relate that to the resources your production workload will use, you can get erroneous results.
In addition, unless you understand how Domino performs the functions, it is possible that you are measuring something quite different from what you think. You could, for example, be measuring network performance instead of server performance. Realistic tests are, unfortunately, complex and expensive to run. Use the information in this document (and the other information sources listed) to get capacity estimates for production workloads.
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.