2017-02-10 173 views
2

根據我們的配置,我們的WAS版本是8.5.5.1,IBM MQ版本7.5.0.3。我們使用2個通道連接WMQ,其中一個MAXINST設置爲250,另一個設爲500. SHARECNV設置爲10。現在我們有一個隊列管理器最多可以建立1600個連接的上限,但是我們在連續運行WAS服務器的3-4天之後最終超過了這個限制。WebSphere MQ高連接計數問題

我想了解WAS端的參數如何影響此計數。我們使用Queue Connection Factory和Act Spec來建立連接,每個連接都有23個。除此之外,Act Spec和QCF中的設置保持默認,如最大服務器會話數= 10,連接池中的最大連接數= 10,會話池中的最大會話數設置爲10.此服務的tps大約爲15-20請求每分鐘。其中22個使用相同的通道連接隊列管理器,並將MAXINST設置爲250. 1獲得相當高的負載,峯值爲每秒80個請求(每個服務器約40個),其中最大服務器會話數= 40,連接池中最大連接數= 40,會話池中的最大會話數設置爲10.連接超時,收穫時間,未使用超時和超時超時值將保持默認值。

通過這些設置,我們最終可以在22個服務使用的信道上連接1200個連接,在連續運行2-3天后,其他信道的連接數將達到500個左右。這些建立一段時間。 現在我想調整這些設置,以便我們不會越過連接數量限制,也不會導致無法連接。 所以,我有幾個問題:

  1. 什麼是視圖 - 業績點降低的連接池或會話池最大會話數最大連接一個更好的選擇。什麼應該是前面提到的負載的理想值。

  2. 默認情況下,連接池和會話池未使用超時的理想值應該是30分鐘。如果我們將其減少到5分鐘,它會對未能獲得聯繫的表現產生什麼影響。

  3. 是否有一些設置可以在WMQ端完成,以便關閉閒置/未使用的連接或只能從客戶端進行。

  4. 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 

我可以看到很多在無連接的和懸浮的狀態,其不具有相關聯的任何OBJNAME或OBJTYPE。 我已經嘗試在測試中模擬這個問題,同樣的事情發生,並且這些連接不斷增加,因爲我們繼續點擊請求。有人能告訴我爲什麼這些連接正在創建。而且它看起來像這些連接永遠不會被應用程序使用。

這是連接是如何製造的,並在應用程序關閉: 我們具有通過擴展的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豆處理在下列方式創建和連接的收盤:

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); 
} 

我還沒有添加編組/解組和其他東西的其他方法。

+0

MAXINST被設置爲250和500只但SHARECNV設置爲10,我們能夠得到比750更多的連接,我們的2500連接,其中1600是用於avaialble SVRCONN通道的上限。 – Neel

+0

@JoshMc此外MAXINSTC設置爲999999999,我猜是默認值。我已經檢查過沒有使用過的連接,當它們達到上限時,對於具有250個實例的通道,通常爲1250,對於具有500個實例的通道,通常爲350。這些設置可能沒有正確設置,因爲應用程序的no服務和負載已逐漸增加,但這些參數並未相應更改。這就是我現在想要做的。 – Neel

+0

使用以下命令:echo「DIS CONN(*)TYPE(CONN)CONNAME CHANNEL」| mqsc -e -m QM1 -p width = 1000 | grep「CHANNEL(A.QM1.CH1)」| wc -l – Neel

回答

1

在做了很多分析並嘗試了不同的WAS和MQ設置之後,我們排除了配置和代碼的任何問題。研究發現以下鏈接http://www-01.ibm.com/support/docview.wss?uid=swg21605479。問題在於Wily Introscope工具用於監視WAS服務器,它正在與MQ建立連接而不釋放它們。我們從服務器中刪除了監控,並且自那時起工作正常。感謝大家的支持。

1

@MoragHughson有一篇IBM developerWorks博文「Avoiding run-away numbers of channels」,詳細介紹了隊列管理器上的各種設置,以限制整個隊列管理器(qM.ini中的MaxChannels)的最大總通道數,單通道(MAXINST)和連接到通道(MAXINSTC)的單臺客戶機。

有MQGem軟件博客文章「MaxChannels vs DIS QMSTATUS CONNS」也@MoragHughson(謝謝莫拉格爲有用的帖子),其進入細節上的連接(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程序,你表明你在註釋中使用。

+0

感謝您分享這個。是的,這是通道之一超過250的通道實例。但是這個計數的建立時間爲2-3天,因此看起來好像實例沒有關閉或者創建新的實例而不是使用現有的實例,因爲負載並不高,甚至在峯值負載時都需要這些實例。我在隊列管理器中檢查了tcp keepalive設置爲yes,並且在隊列連接工廠中將未使用的超時設置爲30分鐘。那麼,什麼可能是這種情況下增長的原因。 – Neel

+0

我確實運行過這些命令,可以看到實例的數量是115,curshcnv在每個實例中在1到10之間變化。發行時這115個達到250個。 – Neel

+0

@Neel根據默認值,如果您有22個不同的WAS實例連接到一個SVRCONN通道,並且它們每個都具有默認值的Act Spec和QCF,則每個實例最多可以使用13個通道,總共可達超過您設置的250 MAXINST的286個通道。我會懷疑這個應用程序沒有完全關閉會話/連接,他們說開放和建立。你如何在應用程序中關閉它們? – JoshMc

0

我們有一個類似的問題,一旦應用程序保持活動狀態持續數小時,連接數就會達到極限。

我們的接觸是調用隊列管理器的隊列管理器的隊列中的disconnect(),而不是close()。所以確保你的finally塊看起來像這樣。

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