How to configure UNIX and Linux systems for IBM MQ

• The IPC semaphore setting 'semmni' failed because it is one quarter the IBM recommended value, even though current semaphore set usage is only at 5%.
• The system file limit 'file-max' is below the IBM recommended value, but because usage is only at 2% and the value is not that far off the IBM default, mqconfig only gave a warning.
• The soft file limit 'nofile' for the user who ran mqconfig is one tenth what it should be. If this user (mqm) starts a queue manager without increasing the soft limit, the queue manager may fail when the system prevents it from opening files.

Notes on mqconfig output

Where possible, mqconfig will try to show your system's current usage as a percentage. If your usage of any resource is nearing the limit, typically 75% or more, then mqconfig may flag it as a warning, even if your value meets or exceeds the IBM default. If your usage is higher still, typically 95% or more, mqconfig may flag it as a failure.



Any values listed in the "Current User Limits" section are resource limits for the user who ran mqconfig. If you normally start your queue managers as the mqm user, then you should switch to mqm and run mqconfig there. If other members of the mqm group (and perhaps root) also start queue managers, they should all run mqconfig to ensure their limits are suitable for MQ.

The mqconfig script may also recommend changing a shell option in order to avoid a known performance problem when running MQ commands in the background. If mqconfig suggests a change, you can modify your profile and log back in again. For example, Korn shell users can add the following line to their .kshrc (or similar) file:


set +o bgnice


The mqconfig script cannot check shell options like bgnice reliably, so run "set -o" in your shell to check the option when mqconfig gives a warning. If the option matches the IBM recommendation you can ignore that mqconfig warning; Otherwise, you should update your login files (like .profile or .kshrc) to set the shell option properly.

If you note a discrepancy between mqconfig and the MQ documentation, or if the mqconfig script fails, please submit a comment using the link a the bottom of the page.

Back to top

Checking WebSphere MQ V6.0 Settings with mqconfig-old

If you are running WebSphere MQ V6.0 or V5.3, you may use the mqconfig-old script to help configure your system. To use mqconfig-old, you must first download the script to your system and make it executable, for example by running: chmod a+x mqconfig-old

mqconfig-old

Syntax


mqconfig-old -?

mqconfig-old -v Version

mqconfig-old -v Version [-p Project]...   (Only on Solaris 10 and later versions)


                Version: 6.0 or 5.3





Options


-?
Prints detailed help information about mqconfig-old.

-v Version
Check your system settings for a specific version of WebSphere MQ (either 6.0 or 5.3).

-p Project
On Solaris 10 and later versions only, system resources are configured using projects. You can provide one or more project names to analyze; otherwise, the mqconfig-old script will analyze any project owning a WebSphere MQ IPC object, or the group.mqm project, or your current project.

Back to top

Operating System Notes

Each operating system has its own parameters and tuning methods.

AIX

The AIX kernel requires no tuning for IPC parameters. Other system settings can be changed using SMIT (System Management Interface Tool).



The mqconfig script will ensure that any relevant AIX operating system HIPER APARs are installed, and it will also check that AIX Unicode data conversion filesets are installed so that MQ can convert data successfully. The mqconfig script will check the resource limits and shell settings for the current user.

HP-UX

HP-UX kernel parameters can be viewed and modified using the System Management Homepage tool (smh) or with the kctune command. The kctune command can also show whether a parameter change will take effect immediately, or whether you must restart the system. On HP-UX 11.23 and older levels, you may use the System Administration Manager tool (sam) instead of smh.



The mqconfig script will verify all of the kernel parameters required by MQ and confirm that PHCO_36900, an important HP-UX patch to libc, is installed on the system. Finally, the mqconfig script will check the resource limits and shell settings for the current user.




Linux

Linux kernel parameters can be changed dynamically using the sysctl command or via files under the /proc filesystem. In order to change parameters permanently, you can add your settings to the /etc/sysctl.conf file or use a system startup script to change the values on each boot.



One oddity is that all semaphore tuning parameters are held in a single parameter called sem, rather than four separate files. All four values must be set at the same time, even if you only wish to change one value.

The mqconfig script will verify all of the kernel parameters for MQ and check the resource limits and shell settings for the current user.



Solaris 9

Solaris 9 kernel parameters can be checked by running the command 'sysdef -i'. To change parameters you must edit the /etc/system file and restart the system.



MQ V7.1 and later versions do not support Solaris 9.



Solaris

Solaris 10 and later versions allow multiple projects, each with their own set of resource limits, rather than relying on a single system-wide set of tuning values. The MQ documentation describes how to use the 'projects', 'projadd' and 'projmod' commands to list, create, and modify projects. The old Solaris 9 kernel parameters have different names, but please note that some begin with "project" and others with "process", as shown here:




• semmni  ▸  project.max-sem-ids
• semmsl  ▸  process.max-sem-nsems
• semopm  ▸  process.max-sem-ops
• shmmax  ▸  project.max-shm-memory
• shmmni  ▸  project.max-shm-ids



In order to use the resource limits recommended by IBM, you should configure a project (for example, 'group.mqm') and make sure you start your queue managers in that project. You can use the 'id' command to check your current project and the 'newtask' command to run a command in a different project, or to start a shell to run multiple commands in a different project:




Using newtask to run one command in a different project


solaris> id -p
uid=500(justinf) gid=501(dev) projid=3(default)

solaris> newtask -p group.mqm strmqm SOHO


WebSphere MQ queue manager 'SOHO' starting.
The queue manager is associated with installation 'MQ75'.
5 log records accessed on queue manager 'SOHO' during the log reply phase.
Log reply for queue manager 'SOHO' complete.
Transaction manager state recovered for queue manager 'SOHO'.
WebSphere MQ queue manager 'SOHO' started using V7.5.0.2.

solaris> id -p


uid=500(justinf) gid=501(dev) projid=3(default)






Using newtask to run multiple commands in a different project


solaris> id -p
uid=500(justinf) gid=501(dev) projid=3(default)

solaris> newtask -p group.mqm

solaris> id -p


uid=500(justinf) gid=501(dev) projid=100(group.mqm)

solaris> strmqm TRIBECA


WebSphere MQ queue manager 'TRIBECA' starting.
The queue manager is associated with installation 'MQ75'.
5 log records accessed on queue manager 'TRIBECA' during the log reply phase.
Log reply for queue manager 'TRIBECA' complete.
Transaction manager state recovered for queue manager 'TRIBECA'.
WebSphere MQ queue manager 'TRIBECA' started using V7.5.0.2.

solaris> runmqlsr -m TRIBECA -t tcp -p 1422 1>/dev/null 2>&1 &

solaris> id -p


uid=500(justinf) gid=501(dev) projid=100(group.mqm)

solaris> exit

solaris> id -p


uid=500(justinf) gid=501(dev) projid=3(default)




If you forget to use the newtask command and start a queue manager in the wrong project (typically the default project), then mqconfig may generate a report which shows lots of warnings and failures for that project. There are two possible solutions:

1. Change the settings for the other project to meet the MQ requirements. This will prevent MQ from failing, even if you forget to use newtask to start your queue managers.
2. Ignore the mqconfig warnings and leave the settings as they are on the other project. Stop any MQ queue managers running in the wrong project and use the newtask command to restart them in the correct project. If you follow this approach, you must be careful about using newtask to start MQ in future.

Back to top

IPC Tuning Parameters

The following parameters control the limits on System V IPC semaphore and shared memory resources used by MQ. Not all parameters exist on every system; AIX notably does not use any of them. Parameters relating to System V IPC message queues are not listed since MQ does not use them.

System V IPC Semaphore Parameters

>  semaem
The maximum adjustment value the operating system can apply when processing an undo request. MQ uses binary rather than counting semaphores, so this parameter does not affect it.

∑  semmni or project.max-sem-ids
The maximum number of semaphore sets on the system. MQ V7.1 and later use fewer semaphore sets than before, and are less likely to run out.

∑  semmns
The total number of semaphores in the system. The theoretical maximum is semmni × semmsl, though in practice some sets will be smaller than the maximum allowed size.

∑  semmnu
The maximum number of semaphore undo requests in the system. When a program ends or crashes, the operating system will automatically adjust semaphores for which undo support was requested. MQ uses this option with some semaphores to ensure they are unlocked even if a process ends abnormally.

>  semmsl or process.max-sem-nsems
The maximum number of semaphores in a single set.

∑  semume
The maximum number of semaphore undo requests a single process can have outstanding.

>  semvmx
The maximum value of a semaphore. MQ uses binary rather than counting semaphores, so this parameter does not affect it.




System V IPC Shared Memory Parameters

∑  shmall

The maximum number of pages available for shared memory on Linux systems.

>  shmmax or project.max-shm-memory
The maximum size of a shared memory set. Setting a very large value will not waste memory since MQ starts by allocating small sets, increasing the size only when processing a heavy workload.

<  shmmin
The minimum size of a shared memory set. There is no particularly compelling reason to use any value other than 1.

∑  shmmni or project.max-shm-ids
The maximum number of shared memory sets on the system. MQ queue managers add shared memory sets based on workload, so it is worth checking this parameter when the system is under load to see how many sets you are using.

∑  shmseg
The maximum number of shared memory sets a single process can attach. This value should match shmmni so that MQ can attach all of the sets it creates.

Back to top