Question

根据我们的配置，我们的WAS版本是8.5.5.1，IBM MQ版本7.5.0.3。我们使用2个通道连接到WMQ，一个MAXINST设置为250，另一个设置为500.两者的SHARECNV设置为10。现在我们有一个上限，在队列管理器中最多可以建立1600个连接，但是在连续运行WAS服务器3-4天之后我们最终会超过该限制。

我想了解WAS端的参数如何影响此计数。我们使用Queue Connection Factory和Act Spec来建立连接，我们每个都有23个。其中22个，Act Spec和QCF中的设置保持默认值，如max server sessions = 10，连接池中的最大连接数= 10，会话池中的最大会话数设置为10.此服务的tps非常低，大约为15-20每分钟请求。所有22个使用相同的通道连接到队列管理器，MAXINST设置为250. 1负载非常高，峰值为每秒80个请求（每个服务器aprox 40），其中max服务器会话= 40，连接池中的最大连接数= 40，会话池中的最大会话数设置为10.连接超时，Reap Time，Unused Timeout和Aged超时值保持默认值。

通过这些设置，我们最终在22个服务使用的频道上建立了大约1200个连接，在连续运行2-3天后，另一个频道大约连接500个连接。这些在一段时间内积累起来。现在我想调整这些设置，以便我们不会超过连接数限制，也不会最终没有可用的连接。所以我有几个问题：

从性能角度来看，有什么更好的选择 - 减少连接池中的最大连接数或会话池中的最大会话数。什么应该是前面提到的负载的理想值。
连接池和会话池的未使用超时的理想值应该是默认设置为30分钟。如果我们将其减少到5分钟，那么它对未能获得连接的性能有什么影响。
是否有一些设置可以在WMQ方面完成，以便关闭空闲/未使用的连接，或者这只能从客户端进行。
DISCINT参数值设置为零，HBINT设置为300.理想值应该是什么。

我跑下面的命令来查看连接

echo "DIS CONN(*) TYPE(*) CONNAME CHANNEL OBJNAME OBJTYPE" | mqsc -e -m     QM-p width=1000 | grep -o '^\w\+:\|\w\+[(][^)]\+[)]' | awk -F '[()]' -v OFS="," 'function printValues() { if ("CHANNEL" in p) { print p["CHANNEL"], p["CURSHCNV"], p["CONNAME"],p["CHSTADA"],p["CHSTATI"],p["LSTMSGDA"],p["LSTMSGTI"],p["OBJNAME"],p["OBJTYPE"],p["ASTATE"] } } /^\w+:/ { printValues(); delete p; next } { p[$1] = $2 } END { printValues() }' | grep MYCHANNEL

MYCHANNEL,,10.215.161.65,,,,,,,NONE
MYCHANNEL,,10.215.161.65,,,,,,,SUSPENDED
    MYCHANNEL,,10.215.161.65,,,,,MYQUEUE01,QUEUE,ACTIVE

我可以看到很多连接在None和暂停状态下没有任何关联的OBJNAME或OBJTYPE。我已经尝试在Test中模拟这个问题，同样的事情发生了，这些连接不断增加，因为我们一直在打击请求。有人能告诉我为什么会创建这些连接。此外，应用程序似乎永远不会使用这些连接。

这是在应用程序中建立和关闭连接的方式：我们有一个abstrack bean类，它由所有MDB扩展

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue") })
public class TrackBeanV2 extends AbstractServiceBean implements MessageListener {//code}

abstrack bean以下列方式处理连接的创建和关闭：

public abstract class AbstractServiceBean {

@Resource(name = "myQCF", type = QueueConnectionFactory.class, shareable = true, description = "Reply Connection Factory")
private ConnectionFactory replyCF; 

@PostConstruct
private void postConstruct() {
        replyConnection = replyCF.createConnection();

    }  catch (JMSException e) {
        throw new RuntimeException("Failed to create JMS Connection");
    }

}
@PreDestroy
private void preDestroy() {
    try {
        replyConnection.close();
    } catch (JMSException e) {
        throw new RuntimeException("Failed to close JMS connection", e);
    }
}

private void sendResponseMessage(String outputMessageText, String jmsMessageID , Destination replyDestination) {
    TextMessage replyMessage = null;
    try {           
        createSession();    
        createProducer();
        replyMessage = createReplyMessage(outputMessageText , jmsMessageID);    
        sendReply(replyMessage, replyDestination);  
        closeProducer();
        closeSession();
    } catch (JMSException exp) {
        handleException(exp);
    }
}
private void createSession() throws JMSException{
    replySession = replyConnection.createSession(true, 0);                  
}`
private void createProducer() throws JMSException{                              
    replyProducer = replySession.createProducer(null);      
}

private void closeSession() throws JMSException {
    if (replySession != null) {
        replySession.close();
    }
}

private void closeProducer() throws JMSException{
    if (replyProducer != null) {            
        replyProducer.close();          
    }
}   
private void sendReply(TextMessage replyMessage, Destination replyDestination) throws JMSException {    
    logMessages(replyMessage.getText(), "RESPONSE MESSAGE");
    replyProducer.send(replyDestination, replyMessage);
}

我没有添加编组/解组等其他类的其他方法。

Answer 1

有一篇IBM developerWorks博客文章＆＃34; Avoiding run-away numbers of channels＆＃34;通过@MoragHughson详细介绍了队列管理器上的各种设置，以限制整个队列管理器的总最大通道数（qm.ini中的MaxChannels），单通道（MAXINST）和连接到通道的单个客户端机器（ MAXINSTC）。

有MQGem软件博客文章＆＃34; MaxChannels vs DIS QMSTATUS CONNS＆＃34;同样由@MoragHughson（感谢Morag提供有用的帖子）详细介绍了连接（DIS CONN）和频道（DIS CHS）之间的差异。

下面是一些可以帮助协调事情的命令（注意我已经在Linux上测试了这些命令，如果你在另一个操作系统上运行而且他们不工作让我知道并且我将会这样做尝试为该操作系统提供一个工作示例：

下面的命令将显示连接标识符，与连接关联的通道名称（如果有）以及IP地址（如果有），输出为CONN,CHANNEL,CONNAME。

echo "DIS CONN(*) CHANNEL CONNAME"|runmqsc <QMGR> | grep -o '^\w\+:\|\w\+[(][^)]\+[)]' | awk -F '[()]' -v OFS="," 'function printValues() { if ("CONN" in p) { print p["CONN"], p["CHANNEL"], p["CONNAME"] } } /^\w+:/ { printValues(); delete p; next } { p[$1] = $2 } END { printValues() }'

以下命令将显示每个正在运行的通道实例，共享对话的数量以及连接到通道的IP地址，输出为CHANNEL,CURSHCNV,CONNAME。

echo "DIS CHS(*) ALL"|runmqsc <QMGR> | grep -o '^\w\+:\|\w\+[(][^)]\+[)]' | awk -F '[()]' -v OFS="," 'function printValues() { if ("CHANNEL" in p) { print p["CHANNEL"], p["CURSHCNV"], p["CONNAME"] } } /^\w+:/ { printValues(); delete p; next } { p[$1] = $2 } END { printValues() }'

上述两个命令都可以调整为使用您在评论中使用的mqsc程序。

Answer 2

在做了更多分析并尝试不同的WAS和MQ设置之后，我们排除了配置和代码的任何问题。虽然研究发现以下链接http://www-01.ibm.com/support/docview.wss?uid=swg21605479。问题在于用于监视WAS服务器的Wily Introscope工具，它正在与MQ建立连接而不是释放它们。我们从服务器上删除了监控，从那时起它工作正常。感谢大家的支持。

Answer 3

我们遇到了类似的问题，一旦应用程序保持活动数小时，连接计数就会达到其限制。

我们的问题是调用queue（）队列管理器postqueue或者dequeue而不是close（）。因此，请确保您的finally块看起来像这样。

finally 
{
    queue.close();
    qMgr.disconnect();     //rather than qMgr.close();      
}

WebSphere MQ高连接计数问题

3 个答案: