Skip to main content

How to configure UNIX and Linux systems for IBM WebSphere MQ - Middleware News

 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

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.

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

adsrerrapop

Popular posts from this blog

IBM Websphere MQ interview Questions Part 5

MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure

IBM Websphere MQ Reason code list / mq reason codes / websphere mq error codes / mq error messages

Reason code list ================= The following is a list of reason codes, in numeric order, providing detailed information to help you understand them, including: * An explanation of the circumstances that have caused the code to be raised * The associated completion code * Suggested programmer actions in response to the code * 0 (0000) (RC0): MQRC_NONE * 900 (0384) (RC900): MQRC_APPL_FIRST * 999 (03E7) (RC999): MQRC_APPL_LAST * 2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR * 2002 (07D2) (RC2002): MQRC_ALREADY_CONNECTED * 2003 (07D3) (RC2003): MQRC_BACKED_OUT * 2004 (07D4) (RC2004): MQRC_BUFFER_ERROR * 2005 (07D5) (RC2005): MQRC_BUFFER_LENGTH_ERROR * 2006 (07D6) (RC2006): MQRC_CHAR_ATTR_LENGTH_ERROR * 2007 (07D7) (RC2007): MQRC_CHAR_ATTRS_ERROR * 2008 (07D8) (RC2008): MQRC_CHAR_ATTRS_TOO_SHORT * 2009 (07D9) (RC2009): MQRC_CONNECTION_BROKEN * 2010 (07DA) (RC2010): MQRC_DATA_LENGTH_ERROR * 2011 (07DB) (RC2011): MQRC_DYNAMIC_Q_NAME_ERROR * 2012 (07DC) (RC201

IBM WebSphere MQ – Common install/uninstall issues for MQ Version on Windows - Middleware News

Creating a log file when you install or uninstall WebSphere MQ WebSphere MQ for Windows is installed using the Microsoft Installer (MSI). If you install the MQ server or client through launchpad , MQPARMS or setup.exe , then a log file is automatically generated in %temp% during installation. Alternatively you can supply parameters on the installation MSI command msiexec to generate a log file, or enable MSI logging system-wide (which generates MSI logs for all install and uninstall operations). If you uninstall through the Windows Add/Remove programs option, no log file is generated. You should either uninstall from the MSI command line and supply parameters to generate a log file, or enable MSI logging system-wide (which generates MSI logs for all install and uninstall operations). For details on how to enable MSI logging, see the following article in the WebSphere MQ product documentation: Advanced installation using msiexec For details on how to enable system-w