For those of you trying to get the most out of your MQ system for Millennium®, a few simple adjustments can deliver big benefits.
WebsphereMQ is an IBM middleware used extensively by Millennium. It has two major roles and one minor role.
- MQ’s most important use is for messages that have to get processed even if an individual application process or an application node crashes. This security measure means the data has to be written to log files and data files on disk drives, making it the slowest type of transaction for MQ.
- The 2007.x and 2010.x versions of Millennium, assuming MQ Shared Services (MQSS) is enabled, use MQ for communication from a client, like Citrix, to the application node. This queuing is non-persistent, meaning if the Citrix client or application node crashes, then the data is lost.
- Several years ago the Foundations team worked with the Foreign System Interface team to allow interfaces to use MQ.
For the first and third uses of MQ, the mqs.ini file defines how the logs are configured. Proper tuning of this configuration can have a tremendous impact on throughput. For MQ 6, several of the older limits have been increased. For HP-UX, AIX and Linux, you can now define up to 510 LogPrimaryFiles and up to 509 LogSecondaryFiles, with a maximum combined total of 511 LogPrimaryFiles and LogSecondaryFiles. This is a significant change from MQ 5.3, where the maximums were 62 and 61, respectively, with a maximum of 63 combined.
Setting these log files to their maximums makes the MQ log filesystems much larger, but it also allows for much greater concurrency. This concurrency allows certain functions — such as adding, updating, deleting and reading information —to run at the same time. It also makes it more likely that long-running batch jobs will complete instead of looping because the log files have wrapped.
Next we’ll look at the setting of my favorite mqs.ini entry, LogWriteIntegrity, which controls how many times a transaction is written to a log file. The default value is TripleWrite, meaning every update has to be written to three log files before the next step in the processing can occur. Why all the redundancy? To be fair to IBM, I believe they recognize that they have no control over the hardware and operating systems MQ is installed on. If your hardware server has no disk redundancy, IBM is giving you a reasonable chance to recover data if your node crashes or your drive dies.
Redundancy, I’m glad to report, is not an issue with Millennium production systems. Even old AIX systems have mirroring, that is, two drives with the identical data on it. If one drive dies, the data is available on the other. On current SANs, a writeback cache typically has a battery backup or a mirroring of the data on different memory arrays. The SANs are normally configured with RAID 5 drives, so the loss of a single drive does not mean any lost data. Thanks to this redundancy, you can change the TripleWrite default of the LogWriteIntegrity entry to SingleWrite. You should see improved MQ performance without risking any of your data.
As far as I know, the Cerner Millennium System Settings (CMSS) have not been updated in this area to help Millennium organizations achieve higher throughput from their investment. If any of you have current access to the CMSS for your operating system and the document is updated to include this, please let me know. I would enjoy hearing that the system tuning is keeping up with newer technology.
One last note, the LogWriteIntegrity parameter is valid on MQ 5.3 as well. You can get more information from IBM’s WebsphereMQ System Administration Guide for Version 6.0 (SC34-6584-00) and WebSphere MQ System Administration Guide for Version 5.3 (SC34-6068-02). Please keep in mind that I recommend you use normal change control processes for this tuning and then migrate any changes into your production environment.
Prognosis: A little MQ tuning goes a long way. You may be surprised at the benefits you see when you increase old log file limits and remove unnecessary redundancies.
