В соответствии с нашей конфигурацией у нас есть версия WAS 8.5.5.1, версия IBM MQ 7.5.0.3. Мы используем 2 канала для подключения к WMQ, один с MAXINST, установленным в 250, и один с 500. SHARECNV установлен для 10 для обоих. Теперь у нас есть верхний предел, заключающийся в том, что в диспетчере очередей устанавливается максимально 1600 подключений, но мы преодолеем этот предел через 3-4 дня непрерывной работы WAS Server.Ошибка подсчета количества подключений WebSphere MQ
Я хочу понять, как параметры на стороне WAS влияют на этот счет. Мы используем Factory Queue Connection Factory и Act Spec для создания соединений, и у нас есть 23 из каждого из них. Из них для 22 настройки в Act Spec и QCF сохраняются по умолчанию, как максимальные сеансы сервера = 10, максимальное соединение в пуле соединений = 10, максимальные сеансы в пуле сеанса равны 10. Эти службы имеют довольно низкие значения tps около 15-20 запрос в минуту. Все 22 из них используют один и тот же канал для подключения к диспетчеру очереди с MAXINST, установленным на 250. 1 получает довольно высокую нагрузку с пиком 80 запросов в секунду (aprox 40 на сервер), для которых максимальное количество сеансов сервера = 40, максимальное соединение в пуле соединений = 40, максимальные сеансы в сеансовом пуле установлены в 10. Тайм-аут соединения, время повторного использования, неиспользуемые таймауты и значения времени ожидания для всех сохраняются по умолчанию.
С этими настройками мы заканчиваем примерно 1200 соединений по каналу, используемому 22 службами, и около 500 для другого канала через 2-3 дня непрерывной работы. Они растут в течение определенного периода времени. Теперь я хочу настроить эти настройки так, чтобы мы не пересекали ограничение количества подключений, а также не приводили к отсутствию соединений. Поэтому у меня есть несколько вопросов:
Что такое лучший вариант с точки зрения производительности View- восстанавливающий макс соединений в пуле соединений или максимум сессий в сеансах бассейне. Какими должны быть идеальные значения для нагрузки, упомянутой ранее.
Что должно быть идеальным значением для неиспользуемого таймаута для пула соединений и пула сеансов, который по умолчанию установлен на 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 связаны. Я пробовал имитировать проблему в тесте, и это происходит, и эти соединения продолжают расти, поскольку мы продолжаем добиваться запросов. Может кто-нибудь сказать мне, почему эти соединения создаются. Также похоже, что эти подключения никогда не будут использоваться приложением.
Это как соединение сделано и закрыто в заявке: У нас есть 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);
}
Я не добавил другие методы класса, которые сортируют/немаршаллируют и другие вещи.
MAXINST установлены как 250 и 500, но с только SHARECNV установлен в 10 мы имеем возможность получить больше соединений, чем 750, то есть верхний предел 2500 для соединений из которых 1600 являются avaialble для каналов SVRCONN. – Neel
@JoshMc Также MAXINSTC установлен в 999999999, что, по моему мнению, является значением по умолчанию. Я не проверял никаких подключений, и когда они достигают верхнего предела, обычно он равен 1250 для канала с 250 экземплярами и 350 для канала с 500 экземплярами.Возможно, эти настройки не были установлены правильно, так как количество приложений и нагрузки постепенно увеличилось для приложения, но эти параметры не были изменены соответствующим образом. Это то, что я хочу сделать сейчас. – Neel
Используя следующую команду: echo "DIS CONN (*) TYPE (CONN) CONNAME CHANNEL" | mqsc -e -m QM1 -p width = 1000 | grep "CHANNEL (A.QM1.CH1)" | wc -l – Neel