сно нашей конфигурации, у нас есть версия WAS 8.5.5.1, версия IBM MQ 7.5.0.3. Мы используем 2 канала для подключения к WMQ, один с MAXINST установлен на 250 и один с 500. SHARECNV установлен на 10 для обоих. Теперь у нас есть верхний предел максимального числа 1600 подключений в администраторе очередей, но в итоге мы пересекаем этот предел после 3-4 дней непрерывной работы WAS Server.

Я хочу понять, как параметры на стороне WAS влияют на этот счет. Мы используем Queue Connection Factory и Act Spec для создания соединений, и у нас есть 23 из них. Из них для 22 параметры в Act Spec и QCF сохраняются по умолчанию, например, максимальное количество сеансов сервера = 10, максимальное число подключений в пуле соединений = 10, максимальное число сеансов в пуле сеансов - 10. Эти сервисы имеют довольно низкую скорость передачи около 15-20. запрос в минуту. Все 22 из них используют один и тот же канал для подключения к администратору очередей с MAXINST, установленным в 250. 1 получает довольно высокую нагрузку с пиком 80 запросов в секунду (приблизительно 40 на сервер), для которого максимальное количество сеансов сервера = 40, максимальное соединение в пуле соединений = 40, максимальное количество сеансов в пуле сеансов установлено равным 10. Значения тайм-аута соединения, времени сбора, неиспользованного времени ожидания и времени ожидания по умолчанию остаются для всех по умолчанию.

С этими настройками мы получаем около 1200 соединений на канале, используемом 22 службами, и около 500 на другом канале после 2-3 дней непрерывной работы. Они накапливаются в течение определенного периода времени. Теперь я хочу настроить эти параметры так, чтобы мы не пересекали предел количества подключений, а также не имели никаких доступных подключений. Итак, у меня есть несколько вопросов:

Что является лучшим вариантом с точки зрения производительности - уменьшение максимального количества соединений в пуле соединений или максимального числа сеансов в пуле сеансов. Какими должны быть идеальные значения для нагрузки, упомянутой ранее.

Каким должно быть идеальное значение для Неиспользованного тайм-аута для пула соединений и пула сеансов, которое по умолчанию установлено на 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

Я вижу много подключений в состоянии «Нет» и состояние «приостановлено», к которым не привязаны ни OBJNAME, ни OBJTYPE. Я попытался смоделировать проблему в тесте, и происходит то же самое, и эти соединения продолжают увеличиваться, поскольку мы продолжаем выполнять запросы. Может кто-нибудь сказать мне, почему эти связи создаются. Также похоже, что эти соединения никогда не будут использоваться приложением.

Вот как соединение создается и закрывается в приложении: у нас есть класс abstrack, который расширяется всеми 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);
}

Я не добавил другие методы класса, которые сортируют / отменяют сортировку, и другие вещи.