You are planning to install or upgrade a WebSphere
MQ server on a UNIX or Linux system and need to know how to tune the
operating system parameters, including kernel parameters related to
inter-process communication (IPC) resources like shared memory and
semaphores.
Cause
If you do not configure your operating system
parameters properly, the WebSphere MQ server may exhaust system
resources when you process your production workload. Depending on the
resource which was exhausted, WebSphere MQ could return an error to the
application like MQRC_RESOURCE_PROBLEM (2012), write a message to its
error logs, create FDC files in the /var/mqm/errors directory, or even
terminate.
Resolving the problem
IBM Recommendations
Using the mqconfig Script
Operating System Notes
IPC Tuning Parameters
Older Version for WebSphere MQ 6.0 and 5.3
Using the mqconfig Script
Operating System Notes
IPC Tuning Parameters
Older Version for WebSphere MQ 6.0 and 5.3
IBM Recommendations |
IBM recommends default values in the WebSphere MQ documentation for several operating system kernel parameters and other tuning values:
-
WebSphere MQ 7.5 Additional settings for AIX, HP-UX, Linux and Solaris
WebSphere MQ 7.1 Additional settings for AIX, HP-UX, Linux and Solaris
WebSphere MQ 7.0 System resource limits for AIX
WebSphere MQ 7.0 Kernel configuration for HP-UX
WebSphere MQ 7.0 Kernel configuration for Linux
WebSphere MQ 7.0 Resource limit configuration for Solaris
These default limits should enable you to run WebSphere MQ without exhausting any system resources. However, if your system is extremely busy, you may need to increase certain values beyond the IBM recommended defaults. A busy system may be running a large number of queue managers, or just a single queue manager with thousands of connected applications and millions of messages, or it may be running another product with high resource demands such as IBM DB2.
If you need to increase parameters beyond the IBM WebSphere MQ defaults, bear in mind that modern systems are capable of supporting large amounts of resources. For example, the UNIX IPC interface was designed in the late 1970s on a 16-bit DEC PDP-11 minicomputer, similar to this one used by UNIX designers Dennis Ritchie and Ken Thompson. Modern systems run with a hundred thousand to more than a million times more memory, so doubling and quadrupling IPC parameters to handle your workload will not stress your system. Be generous with these values and refer to the section on IPC parameters below for more information about specific settings.
Back to top
Using the mqconfig Script |
The mqconfig script analyzes your system and compares its settings to the IBM recommended values for WebSphere MQ 7.5, 7.1 or 7.0. It displays the results of this comparison in an easy to read format, along with a PASS, WARN, or FAIL grade for each setting. The mqconfig script does not make any modifications to your systems. A version called mqconfig-old is available for older versions of WebSphere MQ.
To use mqconfig, you must first download the script to your system and make it executable (e.g. 'chmod a+x mqconfig'), then run it using the syntax given below. On Solaris 10 you should use the '-p' parameter to identify the projects in which you run WebSphere MQ queue managers. If you omit this parameter, mqconfig will try to determine which projects it should analyze, perhaps incorrectly.
-
mqconfig
syntax: mqconfig -?
mqconfig -v Version
mqconfig -v Version [-p Project]... (Solaris 10 only)
Version: 7.5, 7.1 or 7.0
- Example 1: To check your system configuration for WebSphere MQ 7.5:
-
mqconfig -v 7.5
- Example 2: To check your group.mqm and mqdev projects on Solaris for WebSphere MQ 7.1:
-
mqconfig -v 7.1 -p group.mqm -p mqdev
- Example 3: To read the detailed help about mqconfig and resource limits:
-
mqconfig -?
Here is a sample of the mqconfig output showing a Linux system which has four potential tuning issues. The semmni value is half the IBM recommended value, and the nofile soft limit is way too low, which is why both parameters failed. The tcp_keepalive_time limit is unusual in that lower values are better, so here it failed for being too high. Finally, the shmmni value gave only a warning because it is reasonably close to the IBM limit:
Please note that any values listed in the "Current User Limits" section are resource limits which apply to the user running mqconfig. If you normally start queue managers as the mqm user (or via su to mqm) then you should run mqconfig as mqm to verify its user limits. Other members of the mqm group (and perhaps root as well) can also run mqconfig to make sure their user limits are acceptable for starting WebSphere MQ queue managers.
The mqconfig script may also recommend a change to your shell options in order to avoid a performance problem caused when shells run WebSphere MQ background jobs with reduced priority. If your shell is not susceptible then mqconfig will print nothing. If mqconfig suggests a change you can simply modify your profile; For example, Korn shell users can add the line 'set +o bgnice' to their profile.
If you note a discrepancy between mqconfig and the WebSphere MQ Information Center, or if you encounter a problem with the mqconfig script, please submit a comment using the link at the bottom of the page.
Operating System Notes |
AIX
The AIX kernel is self-tuning with regard to IPC parameters, so WebSphere MQ will not run into a limit on shared memory or semaphores. The mqconfig script can check other basic settings to ensure they are suitable for WebSphere MQ.
HP-UX 11i
You can view or change kernel parameters with the System Management Homepage tool (smh) or by using the kctune command. The kctune command can show whether a parameter change takes effect immediately or whether you must restart the system. On HP-UX 11.23 and older, you may use the System Administration Manager tool (sam) instead of smh.
Linux
You can view or change kernel parameters dynamically using the sysctl command or using the files under the /proc filesystem. In order to change the parameters permanently you can add your values to the /etc/sysctl.conf file or use a system startup script to modify the parameters on each startup.
One oddity is that all semaphore tuning parameters are held in a single parameter called sem, rather than individually. The fields in sem correspond to semmsl, semmns, semopm and semmni. All four fields must be set at the same time, even if you wish to change only one value.
Solaris 9
Solaris 9 is supported only by WebSphere MQ 7.0 and older versions. You can view kernel parameters by examining the output of the 'sysdef -i' command. To change parameters you must edit the /etc/system file and then reboot the system.
Solaris 10
Solaris 10 uses projects to replace the system-wide tuning parameters used in previous versions. The WebSphere MQ Information Center describes how to use the projects, projadd and projmod commands to list, create and modify projects. The previous kernel parameters have received more descriptive names, but note that some begin with 'project' and others with 'process' as shown below:
Old Name |
New Name |
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 ensure that you start queue managers in that project. You can check your current project using the id command and use the newtask command to run a single command or start a shell in a different project. The following example demonstrates both methods, with the commands on the dark gray background running in the group.mqm project rather than the default project:
sun10> id -p uid=500(justinf) gid=501(dev) projid=3(default) |
sun10> newtask -p group.mqm strmqm SOHO WebSphere MQ queue manager 'SOHO' starting. The queue manager is associated with installation 'Manhattan'. 5 log records accessed on queue manager 'SOHO' during the log replay phase. Log replay for queue manager 'SOHO' complete. Transaction manager state recovered for queue manager 'SOHO'. WebSphere MQ queue manager 'SOHO' started using V7.1.0.0. |
sun10> id -p uid=500(justinf) gid=501(dev) projid=3(default)
sun10> newtask -p group.mqm
|
sun10> id -p uid=500(justinf) gid=501(dev) projid=100(group.mqm)
sun10> strmqm CHELSEA
WebSphere MQ queue manager 'CHELSEA' starting. The queue manager is associated with installation 'Manhattan'. 5 log records accessed on queue manager 'CHELSEA' during the log replay phase. Log replay for queue manager 'CHELSEA' complete. Transaction manager state recovered for queue manager 'CHELSEA'. WebSphere MQ queue manager 'CHELSEA' started using V7.1.0.0.
sun10> exit
|
sun10> id -p uid=500(justinf) gid=501(dev) projid=3(default) |
It is easy for WebSphere MQ queue managers to end up running in the default project, for example because an administrator forgot to use the newtask command. You should either configure the default project to satisfy the IBM WebSphere MQ default tuning values, or put processes in place to ensure that WebSphere MQ commands run in the right project.
IPC Tuning Parameters |
The following parameters control Inter-Process Communication (IPC) semaphore and shared memory resources used by WebSphere MQ. Not all parameters exist on every system; AIX, for example, does not use any of these parameters. Parameters relating the IPC message queues are not listed since WebSphere MQ no longer uses them.
If you are installing WebSphere MQ on a system with other products that recommend certain IPC parameter settings. In some cases (marked with an asterisk in the table below) you should add up the recommendations of all the products and use the total. For example, if WebSphere MQ recommends 1024 and DB2 recommends 1024, choose a value of 2048 or higher. Otherwise you should use the highest requested value. For example, if WebSphere MQ wants a value of 256 and DB2 asks for 512, you should use the higher value of 512.
Parameter |
Description |
semmni * |
The maximum number of semaphore sets on the system. WebSphere MQ queue managers add sets based on workload, so you should check this parameter at runtime to ensure the resource usage is safely within your limit. |
semmsl |
The maximum number of semaphores in a single set. |
semmns * |
The total number of semaphores in the system. You can calculate the theoretical maximum by multiplying semmni * semmsl, but in practice some sets will have fewer than the maximum number of semaphores. |
semmnu * |
The maximum number of semaphore undo requests in the system. When a program ends or crashes, the operating system will automatically release semaphores for which "undo" support was requested. WebSphere MQ uses the undo option with some semaphores to ensure they will not get stuck in a locked state. |
semume * |
The maximum number of semaphore undo requests a single process can make. |
semaem |
The maximum adjustment value the operating system can apply to a semaphore when processing an undo requests. Since WebSphere MQ uses binary rather than counting semaphores, this parameter does not affect it. |
shmmni * |
The maximum number of shared memory sets on the system. WebSphere MQ queue managers add sets based on workload, so you should check this parameter at runtime to ensure the resource usage is safely within your limit. |
shmseg * |
The maximum number of shared memory sets a single process can attach. This value should match shmmni so that WebSphere MQ processes can attach all sets, if necessary. |
shmmax |
The maximum size of a shared memory set. Setting a large value will not waste memory on your system since WebSphere MQ starts by allocating small set, and allocates large ones only when it is processing a heavy workload. |
shmmin |
The minimum size of a shared memory set. There is no compelling reason to use any value other than 1. |
shmall * |
The maximum number of pages available for shared memory on Linux systems. |
semvmx |
The maximum value of a semaphore. WebSphere MQ does not use counting semaphores, so this parameter does not affect it. |
Older Version for WebSphere MQ 6.0 and 5.3 |
The mqconfig-old script is an older version for WebSphere MQ 6.0 and 5.3 which will be withdrawn after WebSphere MQ 6.0 ends support on September 30, 2012. To use mqconfig-old, you must first download the script to your system and make it executable (for example 'chmod a+x mqconfig-old'), then run it using the syntax given below. On Solaris 10 you should use the '-p' parameter to identify the projects in which you run WebSphere MQ queue managers. If you omit this parameter, mqconfig-old will try to guess which projects it should analyze.
mqconfig-old
syntax: mqconfig-old -?
mqconfig-old [-v 6.0|5.3]
mqconfig-old [-v 6.0|5.3] [-p Project]... (Solaris 10 only)
Comments
Post a Comment