WebSphere MQ连接调整

问题描述

我有一个使用MDB，激活规范和队列连接工厂从WMQ获取/发送消息的应用程序.该应用程序预计最大负载为80 tps. Websphere Application Server和WMQ都是集群的，每个应用程序服务器都连接到单独的主机和通道.应用程序onMessage方法是通过某种方式实现的，以便在消息被消耗并发送响应之后，会话和连接都将关闭.

I have an application which uses MDB, activation specifications and Queue Connection Factories to get/put Messages from WMQ. The application expects a max load of 80 tps. Both Websphere Application Server and WMQ are clustered and each application server connects to seperate host and channel. The application onMessage method is implemented in way so that both session and connection gets closed after message is consumed and response is sent.

根据我们的配置，我们的WAS版本为8.5，IBM MQ队列管理器版本为7，每个节点的行为规范的最大服务器会话数设置为40.每个节点的连接工厂中的最大连接数为40，连接工厂的会话池中的最大会话数为10.现在，在峰值负载下，我们预计最多可以创建80个MQ通道实例，但是根据调查，我们可以看到它超过200个，这导致达到最大实例限制时出现问题.

As per our configuration, we have WAS version is 8.5, IBM MQ queue manager version 7, max server sessions for act spec set to 40 for each node. max connection count in Connection Factory to 40 for each node and max session in session pool of connection factory to 10.Now on peak load we expect to make max 80 MQ Channel Instance but as per the investigation we can see it goes above 200 which is causing an issue as max instance limit is reached.

这是由于连接工厂的会话池中的最大会话数设置为10引起的吗?

Is this happening because max session in session pool of connection factory is set to 10?

即使我们正在onMessage中关闭会话和连接，仍然有可能一个连接可以有多个会话.如果是这样，将此属性设置为1是否明智?还可以在WMQ处设置一些属性，这可能会导致MQ通道实例的数量增加.

Is it possible that even though we are closing the session and connection in onMessage, still one connection can have more than one session. If that is the case, is it wise to set this property to 1?Also can there be some property set at WMQ which could cause this increase in MQ Channel Instances.

推荐答案

您没有提到WAS或MQ的特定版本，并且特定版本中可能存在已知问题，这会改变行为，但总的来说应该如下所述.

You don't mention specific versions of WAS or MQ, and there could be known problems at a specific version that would change the behavior, but in general it should work as described below.

IBM有一个很好的技术说明" WebSphere之间的TCP/IP连接用法解释了Application Server V7和V8，以及WebSphere MQ V7(及更高版本)".

IBM has a nice Technote "TCP/IP Connection usage between WebSphere Application Server V7 and V8, and WebSphere MQ V7 (and later) explained" which goes into detail on this subject.

您不会提及将SVRCONN通道的SHARECNV设置为什么，因为这将影响观察到的通道实例的数量，我将假定默认值为10.

You do not mention what you have the SVRCONN channel's SHARECNV set to, as per below this will impact the number of channel instances observed, I'll assume the default of 10 for the calculations.

请注意，下面的块引文来自Technote

Note that block quotes below are from the Technote

• 我们已将每个节点的行为规范的最大服务器会话次数设置为40

上面的链接指出:

最大会话数= 40 + 1 = 41

Maximum number of conversations = 40 + 1 = 41

该链接还指出:

TCP/IP 通道实例的最大数量 = 41 / 10 = 5 (四舍五入到最接近的连接)

Maximum number of TCP/IP channel instances = 41 / 10 = 5 (rounded up to nearest connection)

每个节点的
• 最大连接计数为40
连接工厂到10的会话池中的
• 最大会话次数.

• max connection count in Connection Factory to 40 for each node
• max session in session pool of connection factory to 10.

最大会话数= 40 + (40 * 10) = 440

Maximum number of conversations = 40 + (40 * 10) = 440

TCP/IP通道实例的最大数量= 440 / 10 = 44

Maximum number of TCP/IP channel instances = 440 / 10 = 44

如果您的MQ SVRCONN通道的SHARECNV设置为10，则基于连接到单独通道的每个节点，每个通道最多应有49个通道实例.

If your MQ SVRCONN channel's SHARECNV was set to 10, then you should have no more than 49 channel instances for each channel based on each node connecting to a separate channel.

如果您要访问200个通道实例，我会怀疑您的SHARECNV小于10.如果为1，则WAS尝试创建的最大通道实例数将达到481，这将受到以下限制:通道200的MAXINST.

If you are hitting 200 channel instances I would suspect your SHARECNV is less than 10. If it was 1 the the maximum number of channel instances WAS would try to create would go up to 481 which would be limited by the MAXINST of the the channel to 200.

从WebSphere MQ消息传递提供程序Connection Factory创建的每个JMS Connection都有一个关联的JMS会话池，其工作方式与连接池相同.可以从单个JMS连接创建的最大JMS会话数由连接工厂会话池属性最大连接数"确定.此属性的默认值为10.

Every JMS Connection that is created from a WebSphere MQ messaging provider Connection Factory has an associated JMS Session Pool, which work in the same way as Connection Pools. The maximum number of JMS Sessions that can be created from a single JMS Connection is determined by the Connection Factory Session Pool property Maximum connections. The default value of this property is 10.

首次创建JMS会话时，将启动一个对话，该对话将保持活动状态，直到关闭JMS会话为止，因为该对话在Free Pool中的保留时间超过了Session Pool的Unused timeout属性值.

A conversation is started when a JMS Session is first created, and will remain active until the JMS Session is closed because it has remained in the Free Pool for longer than the value of the Session Pool's Unused timeout property.

当您的应用关闭onMessage中的会话和连接时，将连接移至空闲池以供重用，并将会话移至空闲池以供重用，直到遇到相应的超时，MQ Channel实例才会关闭

When your app closes the session and connection in onMessage, the connection is moved to the free pool for reuse and the session is moved to the free pool for reuse, the MQ Channel instance will not be closed until the respective timeout is hit.

如果要将最大通道数保持在200以下，则可以将会话池最大连接数" 调整为1，再加上激活规范，则SHARECNV(1)的最大值为121个频道实例.

If you want to keep your maximum channel count less than 200 then you could tune your Session Pool Maximum Connections) to 1 which combined with your Activation Specifications and a SHARECNV(1) would max out at 121 channel instances.

您还可以增加通道的SHARECNV值，这将导致通道实例除以该数字.

You can also increase the SHARECNV value of the channel which will result in dividing the channel instances by that number.

您的连接或会话可能无法正确关闭，并且出现泄漏".

It is possible that your connections or sessions are not getting closed properly and you have a "leak".

这篇关于WebSphere MQ连接调整的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！