Some programmers are familiar with techniques for tuning Lotus Domino for AS/400. The most common of those techniques are setting NSF_Buffer_Pool_Size_MB appropriately, limiting the number of active users per Domino partition or server, and tuning AS/400 communication lines. Performance tuning is a dynamic “art,” and I’d like to show you some new tuning tricks that you can implement to improve the performance of your Domino servers. Some of these new tricks include changing individual Domino job runtime priority level, optimizing online back-up times through Backup, Recovery and Media Services for the AS/400 (BRMS/400), and using the new platform statistic support to collect AS/400 performance statistics in your Domino server.
Domino Subsystem Tuning
With Domino 5.0, you can change the priorities of Domino jobs permanently. Before 5.0, any changes to the runtime priority of a Domino job lasted only for the life of the job. If you stopped and restarted the Domino subsystem, the priorities of the jobs that had been changed were reset to the original runtime priorities. With 5.0, you can permanently set a Domino job to run at a priority other than the default priority 20. This setup is a two-step process.
First, you need to create a new job class to define which runtime priority you would like to select. The runtime priority can be anything from 10 to 99. The higher you set the runtime priority number, the lower the actual run priority will be: A job with a runtime priority of 20 will get more CPU cycles (i.e., have a higher runtime priority) than a job that has a runtime priority of 30. Use the Create Class (CRTCLS) command for this step. As an example, I am going to create a class with a runtime priority of 30. The name of the class is mailclass, and it will reside in the AS/400 library QUSRNOTES. All classes that are going to be used to change the runtime priority of a Domino job or task must be created in library QUSRNOTES. The actual command to create this class is as follows:
crtcls cls(qusrnotes/mailclass) runpty(30)
The next step is to tell a Domino subsystem which jobs (or tasks) should use this class. Domino for OS/400 looks for this information in a file named /qibm/userdata/lotus/notes/domino_classes in the AS/400 Integrated File System (AS/400 IFS). There are various ways to edit this file. I will use the OS/400 Edit File (EDTF) command to edit the file. (I could also edit the file by using the Operations Navigator Edit option or by mapping a network drive to the AS/400 and editing as I would any PC-type file with a utility such as Microsoft Word.) Chances are that this file will be empty the first time I edit it; this is normal. All Domino servers on the system will reference this class upon startup to see if alteration of the runtime priority of any jobs/tasks is required. Once I have edited the file /qibm/userdata/lotus/notes/domino_classes to indicate which tasks will use the new runtime priority through the class just created, my screen will look like the one in Figure 1.
I’ll need three keywords to signal the Domino server to change the priority of a task: SERVER, CLASS, and TASKS. SERVER identifies the name of the Domino server that I want to work with. CLASS specifies the name of the class I created in library QUSRNOTES that indicates the new runtime priority. TASKS lists the Domino jobs that should use the new class to obtain their runtime priority. It is very important to list the keywords in this particular order.
The first Domino server I want to work with is Mail01, and the class that has been created to specify the new runtime priority is mailclass. Now I need to tell the Domino server which tasks will use the new priority; I’ve specified calconn and router. If I want to work with the same Domino server but use a different class to specify yet another runtime priority for additional tasks, I would list the keyword CLASS to specify the new class: mailclass2. Next, I use the keyword TASKS to indicate that the task sched will use the runtime priority associated with mailclass2.
Each time the calconn and router jobs are started for Domino server Mail01, they will obtain the runtime priority that was defined in class mailclass: 30. The Domino task sched, which is still associated with Domino server Mail01, will have yet another runtime priority: the priority associated with class mailclass2. As the file /qibm/userdata/lotus/ notes/domino_classes is referenced for all Domino servers on a given AS/400, you can change the runtime priority of a task on a different Domino server by specifying the server with the keyword SERVER and then referencing the CLASS and TASKS that you want to utilize the new runtime priority. I will work with the next Domino server by specifying the keyword SERVER and providing the name of the server, App01. The keyword CLASS is next; it specifies the new class appclass. And then TASKS lists the task—agent manager (Amgr)—that will use the new runtime priority of class appclass.
At this point, the only other thing I need to do for the new runtime priorities of these tasks to take effect is stop and restart the affected Domino servers. You can do this through either the OpsNav client, a Domino administration client, or the Work with Domino Servers (WRKDOMSVR) command on the AS/400 command line.
For a detailed list of Domino tasks, refer to the administration’s help database, which you can find in the help folder in the server’s data directory. You can change the runtime priority of all Domino tasks, but it is recommended that you not change the priority of the SERVER or QNNINSTS tasks. These tasks are integral to the functioning of the Domino server, and, therefore, you should leave their runtime priorities at the default of
20. The capability of changing the priority of individual Domino jobs was introduced in R5 of Domino on the AS/400, and it requires OS/400 V4R3 or later.
Saving Your Domino Configuration Is Easy
With V4R4, Domino for AS/400 R5.0.2a supports online backup capability with BRMS/400. Prior to this support, there was no true online backup option for saving Domino databases. With this latest support (provided in PTF SF60285 for BRMS/400),
you can now save Domino databases on the AS/400 while they are in use, with no save- while-active synchronization points.
There are some tricks that will improve the performance of your save operation when using BRMS with your Domino databases. The Domino databases will be saved in groups because writing individual Domino databases to physical devices would not provide acceptable performance. The default group size is five Notes/Domino databases. You can change this group size by adding the following variable in the notes initialization (notes.ini) file for a given Domino server:
SAVDOMBRM_FILES_IN_GROUP=x
The value specified for x indicates the number of files to group into one BRMS package. The maximum group value is 120. As the size of the group increases, the length of your Domino BRMS save operation decreases.
The group size that is appropriate for your save operation depends on when the actual backups occur. If the Domino server is being backed up during off-peak hours, when server usage is low, it is better to change the group size to a larger number, such as 10 to 20 or even higher. On the other hand, if you back up Domino databases when the server has heavy usage, you should keep the group value much smaller. In most cases, the default setting of five will be sufficient, but you may want to reduce the group size to as small as three.
The group size that you use during saves will have an impact on recovery times as well. All databases in the group are journaled during the backup. All changes are backed up separately. Because all the databases in the group are journaled until all are backed up, the time during which changes to the databases can occur is increased and the size of the changes that are backed up will increase. When the databases are recovered, the changes to the database that occurred during the backup will be reapplied. This process takes longer as the number of changes increases. For more information, refer to the Backup, Recovery and Media Services Web site at www.as400.ibm. com/service/brms/domino.htm.
Statistics Confirm Your Plan
New support has been added to Domino R5.0.3 for AS/400 that makes it easier to analyze operating system performance metrics. Prior to this support, it was necessary not only to look at the Domino statistics but also to look at OS/400 statistics through the performance tools. To avoid this two-step process, Domino has made it possible to collect operating system performance information on the Domino server. This feature is disabled by default in R5.0.3 and later releases. You can enable it by adding the following variable to the notes.ini file and stopping and restarting your Domino server:
PLATFORM_STATISTICS_ENABLED=1
Domino can now track OS/400 performance metrics, such as CPU utilization, disk I/O, process, and memory use. Type show stat platform at the Domino console to display the statistics. Performance statistics will be collected continuously until the support is disabled or reset or the server is ended. The server will reset the statistics each time you stop and restart it.
The system statistics are collected for the whole system. The same information is reported for each Domino server or partition. For instance, Platform.
System.TotalUtil indicates the total CPU utilization for all processors on the system.
The memory statistics that are reported for a Domino partition or server will report statistics for the memory pool that the partition is running in. If more than one partition is
running in a memory pool, then the values reported will include activity for all partitions, such as the following:
• Platform.Memory.FaultsPerSec indicates the number of page faults per second in the memory pool this Domino server is running in (usually QBASE).
• Platform.Memory.PagesPerSec calculates the number of pages per second read to or written from the disk in the memory pool this Domino server is running in.
The process statistics for each partition are independent of other partitions. When multiple jobs are required to do the same task, statistics can be collected for up to four of the processes. These are jobs such as agent manager (Amgr), SERVER, replication (REPLICA), and UPDATE. If there are more than four instances of a single process in a partition, only the first four will be saved and reported in the statistics, as follows:
• Platform.Process.SERVER.1.Util—CPU utilization of the first server process for this Domino partition
• Platform.Process.SERVER.2.Util—CPU utilization of the second server process of this partition
• Platform.Process.SERVER.3.Util—CPU utilization of the third server process of this partition
• Platform.Process.SERVER.4.Util—CPU utilization of the fourth server process of this partition
• Platform.Process.AMGR.1.Util—CPU utilization of the first agent manager for this partition
Disk statistics are collected for the whole system. All configured disk units in all auxiliary storage pools (ASPs) are collected as follows:
• Platform.LogicalDisk._Total.1_Total.1.PctTime—average percentage of all disk units on the AS/400 that are busy
• Platform.LogicalDisk._Total.1._Total1.PctUsed—percentage of all configured disk units in all ASPs that is currently allocated for data
To change the collection interval, reset statistics, or stop the collection process, you can use four different arguments with the platform command: TIME, RESET, WAIT, RUN. These arguments perform the following tasks:
• Platform time displays the current sampling rate; the default is 1 minute.
• Platform time 5 changes the sampling rate to every 5 minutes.
• Platform reset resets the statistics and restarts the collection process.
• Platform wait pauses collection of the performance data.
• Platform run resumes collection of the performance data.
These new statistics should make Domino performance analysis easier for everyone. However, you may still need to use the OS/400 performance tools. For more information on the new platform statistics tool, see the Lotus Domino for AS/400 5.0.3 Release Notes at www.as400.ibm.com/domino/QMR503.htm.
Performance Is a Perennial Problem
Release 5.0 of Domino offers a number of performance enhancements for not only tuning Domino but also integrating the collection of performance data. With the ability to apply runtime priority changes to individual Domino jobs, Domino is now able to fully take advantage of the AS/400 architecture. This level of performance tuning granularity is unparalleled on any other platform.
The world of performance analysis and tuning is always changing, so keep your ears open and eyes peeled as more great functions within Domino become available. To help you keep abreast of this ever-changing world of tips and tricks, place a bookmark at IBM’s Domino Performance Web site at www.as400.ibm.com/developer/ domino/perform. This site contains two white papers that I originally wrote that are continually updated with the latest AS/400 Domino performance tuning recommendations. Happy tuning to you.
REFERENCES AND RELATED MATERIALS
• Backup, Recovery and Media Services Web site: www.as400.ibm.com/service/brms/domino.htm
• IBM Domino Performance Web site: www.as400.ibm.com/developer/ domino/perform
• Lotus Domino for AS/400 Quarterly Maintenance Release 5.0.3 Web site: www.as400.ibm.com/domino/QMR503.htm
Figure 1: Edit the file /qibm/userdata/lotus/notes/domino_classes to indicate which tasks will use the new runtime priority through the new class you create.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online