Avoiding run-away numbers of channels
Morag Hughson 110000EQPN Comments (3) Visits (4037)
As an administrator of a WebSphere MQ Queue Manager, you have the job of ensuring that the system runs smoothly and that a badly behaving application cannot have an impact on other users of the queue manager. One of the ways you ensure this happens is to restrict the number of channels that can run, thus avoiding problems when too many channels use up resources on the system, such as memory.
Traditionally this was done by setting a value for the overall queue manager that set a maximum on the number of channels that could be run in the queue manager.
On distributed in the qm.ini file:
Channels: MaxChannels: 500
On z/OS using the following command:
ALTER QMGR MAXCHLS(500)
These equivalent settings allowed you to ensure that the number of channels running in the queue manager did not exceed what the queue manager was capable of running on that machine, taking into account the memory available, threads, sockets and any other pertinent resources.
It did not however protect your queue manager from a badly behaved application, running as a client, "eating up" all your slots for channels and getting your queue manager into a state where you can't start a sender channel because 500 instances of a server-connection channel are running. This can happen if the client application connects, but does not disconnect before making another connection.
Protecting Max Channels
In WebSphere MQ V7.0 an attribute was added that allows you to configure your queue manager to avoid such an issue. This attribute is called MAXINST and is available to set on a server-connection channel. It sets a maximum number of client-connection channels that can connect to that named server-connection channel concurrently. Here is an example:
Interaction between Max Channels and Max Instances
The original maximum value for the overall number of channels still applies. Here we are going to look at how they interact and give some advice on how to set them.
For each server-connection channel you have defined on your queue manager, set the MAXINST value to the number of instances you expect to need. Now total up all the MAXINST values. Your aim is to get the total to be less than the value set for Max Channels. The reason you want the total to be less that the overall maximum is because you need a little space for your non server-connection channels, that is your queue manager to queue manager channels, such as senders and receivers.
Here are some sums:
Number of sending MCA channels: #send + Number of receiving MCA channels: #recv + Total of all MAXINST: #clients + -------- Set Max Channels to this: #total
When counting up your sending MCA channels for the above sum, remember to include SENDER, SERVER and CLUSSDR channel types.
When counting up your receiving MCA channels for the above sum, remember to include RECEIVER, REQUESTER and CLUSRCVR channel types, and additionally remember that multiple inbound connections may connect to these types of channels, so it is likely to be a greater number than just the number of definitions.
Protecting Max Instances
So now your queue manager is configured so that no single server-connection channel can use up all the slots in Max Channels and stop you from being able to start a sender channel. However, a single client machine can still use up all the slots you have defined for use on a server-connection channel. If your server-connection channel is shared by a number of client machines, as is often the case, then one badly behaved client machine can use up all the slots and stop another client machine from being able to connect. So we can take this protection one step further. We can also protect Max Instances.
To ensure that no single client machine can use up all the slots available on one server-connection channel, we can set a value for MAXINSTC. This is a per client version of MAXINST. So no single client machine can have more than the number set in there. If you are sharing a server-connection channel between a number of client machines, it is wise to MAXINSTC to a value lower than MAXINST is set to on that server-connection channel.