Sunday, April 14, 2013

Improve your Domino Server Performance on the System i

On Windows it is pretty clear that Domino Servers only perform well, when the admin regulary defragment the file system where the Domino data is stored. Unfortunatly many System i admins do not know that fragmentation of Domino databases is a problem on their system too. So they do not get the best performance possible and with every year of using the server the problem of framgentation gets bigger and bigger.

The defragmentation of the disks in a System i Server can be done with the command STRDSKRGZ.

So login into your System i with a 5250 Terminal client and execute the STRDSKRGZ command:


The ASP Parameter means that you want to reorganize all Auxilliary Storage Pools (Normally you have only one of this, but if you have more of them, then *all handles them all)

The Timlmt(*NOMAX) means that the System i should defragment the ASP till all data is complete defragmented. As an alternative you can specify a exact time how long you want do defrag the disk. Disk reorganization stop automatically when the timelimit is reached.

As the disk reorganization runs in the background and on a very small runtime priority, you do not have to stop your domino server or other system i tasks running.

When you want to stop the reorganization before it is finished or the time limit has elapsed you can use the ENDDSKRGZ command.


When a disk reorganization is started a CPI1470 Message is logged in the System i log and when the reorganization finishes a CPI1472 message is logged. You can find the reason why the execution hast stopped in the message details of CPI1472.

You can scan the System i log for this messages with the DSPLOG command.


So give your Domino server on the the system i a performance boost and execute the disk reorganization regulary. My suggestion is to add the command to the job scheduler of the System i.


  1. Hi Ralf,

    Defragmentation of DASD on IBM i is really not needed. The architecture of IBM i single level storage eliminates the need for system interaction with disk drives, cylinders, etc., in that the operating system (IBM i) sees a logical storage space and the Licensed Internal Code manages it underneath the covers. Single level storage scatters objects across all physical disks allowing all drive arms to concurrently access these objects for maximum performance.

    I don't believe this command is intended to be run as a regular maintenance task unless you're running a system with a very high amount of used space for a very long time which will usually result in message CPI0997 being logged to the QSYSOPR message queue. If it comes to that, I'd recommend more disk needs to be added to the box.

  2. Hi Steve!

    I am aware of the benefits of the single level storage architecture of the i. But sls is not magic. Deep down in the licensed internal code there is a data structure (Storage directory) which tracks all fragments of data on the disks. And with this data structure becomes to big you will see a performance degradation or in worst case a CPI0999 Storage Directory Treshold is reached will be issued. In this case you have to do a STRDSKRGZ immediatly or your ibm i will crash.

    IBM is recommending to run STRDSKRGZ from time to time in technote

  3. Hi Ralf,

    No, I agree single level storage is not magic. However it's a defining characteristic of IBM i which makes it superior compared to most other operating systems. :)

    While it may be useful in terms of systems with extremely high disk utilization, the performance increases I've seen on systems that this command has been ran on have been very modest at best. If it floats your boat, go for it. I just don't see the need if running a system with adequate and properly sized storage. Also, I don't see in the technote how often they recommend to run it as a measure of preventative maintenance. The technote really needs some clarity.

  4. Aha, and therin lies the rub: 'just don't see the need if running a system with adequate and properly sized storage'
    With System i and Domino being systems that are usually low maintenance and long running, the 'adequate and properly sized' bit might be well off. And so a little timely maintenance would offer enhanced performance and stave of bigger investments.