2017-02-07 3 views
2

У меня есть приложение, которое использует MDB, спецификации активации и фабрики подключения очереди, чтобы получать/отправлять сообщения из WMQ. Приложение ожидает максимальной нагрузки 80 tps. Оба сервера Websphere Application Server и WMQ группируются, и каждый сервер приложений подключается к отдельному хосту и каналу. Метод onMessage приложения реализуется таким образом, чтобы и сеанс, и соединение закрывались после того, как сообщение было уничтожено и отправлен ответ.Настройка соединения WebSphere MQ

В соответствии с нашей конфигурацией у нас есть версия WAS: 8.5, диспетчер очереди IBM MQ версии 7, максимальные сеансы сервера для набора действий для 40 для каждого узла. максимальное количество подключений в Connection Factory до 40 для каждого узла и максимальный сеанс в сеансовом пуле фабрики подключений до 10. Теперь, когда пиковая нагрузка рассчитывается, максимальная пропускная способность канала составляет 80 MQ, но, согласно исследованию, мы видим, что оно превышает 200, что вызывает проблему при достижении максимального предела экземпляра.

Это происходит, потому что максимальная сессия в сеансе пула подключения фабрики установлена ​​на 10?

Возможно ли, что даже если мы закрываем сеанс и соединение в onMessage, одно соединение может иметь более одного сеанса. Если это так, целесообразно ли установить это свойство в 1? Также может быть некоторое свойство, установленное в WMQ, которое может вызвать это увеличение в экземплярах канала MQ.

+0

WAS версия 8.5. IBM MQ queue manager версии 7. Версия адаптера ресурса MQ. Я не знаю сейчас, но должен быть тем, что приходит по умолчанию. Было ли это 8.5 – Neel

ответ

2

Вы не упомянули конкретные версии WAS или MQ, и могут быть известные проблемы в конкретной версии, которая изменит поведение, но в целом она должна работать, как описано ниже.

IBM имеет приятный технот «TCP/IP Connection usage between WebSphere Application Server V7 and V8, and WebSphere MQ V7 (and later) explained», который подробно освещает эту тему.

Вы не упомянули, что у вас установлен канал SHARECNV канала SVRCONN, как показано ниже, это повлияет на количество наблюдаемых экземпляров канала. Предположим, что для вычислений используется значение по умолчанию 10.

Обратите внимание, что блок котировки ниже от Technote


  • мы установили макс сервера сеансов для акта спецификации к 40 для каждого узла

Ссылка выше заявляет:

Максимальное количество разговоров = Максимум сеансов сервера + 1

Максимальное количество разговоров = 40 + 1 = 41

Ссылка также утверждает:

Максимальное количество TCP/IP экземпляры каналов = Максимальное количество разговоры/SHARECNV для канала используется

Максимальное количество TCP/IP экземпляров канала = 41/10 = 5 (округлено до ближайшего соединения)


  • макс соединение счет в соединении Factory с 40 для каждого узла
  • макс. Сессия в сеансе пула подключения завода к 10.

Максимальное количество разговоров = пул соединений Максимальное число подключений + (пул соединений Максимальное число подключений * пула сеанса Максимальное число подключений)

Максимальное количество разговоров = 40 + (40 * 10) = 440

Максимальное количество экземпляров канала TCP/IP = Максимальное количество разговоров/SHARECNV для используемого канала

Максимальное количество экземпляров TCP/IP канала = 440/10 = 44


Если ваш канал MQ SVRCONN-х SHARECNV был установлен 10, то вы не должны иметь не более 49 экземпляров канала для каждого канала на основе на каждом узле, соединяющем отдельный канал.

Если вы ударяете 200 экземпляров канала Я подозреваю, ваш SHARECNV меньше 10. Если бы это было 1 максимальное количество экземпляров канала будет пытаться создать бы до 481, которая будет ограничена по MAXINST из канал до 200.


После того как приложение закончит с Connection JMS и закрыл его, он перемещается из активного пула в пул свободного, где он доступен для повторного использования. Свойство Connection Pool Неиспользуемый тайм-аут определяет, как долго JMS-соединение останется в свободном пуле до его отключения. Это свойство имеет значение по умолчанию 1800 секунд, что составляет 30 минут.


Каждый JMS Connection, который создается с завода поставщика сообщений подключения WebSphere MQ имеет ассоциированную JMS Session Pool, которые работают точно так же, как пулы подключений. Максимальное количество сеансов JMS, которые могут быть созданы из одного JMS-соединения, определяется свойством Connection Factory Session Pool Maximum Maximum. Значение по умолчанию этого свойства равно 10.

Разговор начинается, когда сеанс JMS сначала создается и будет оставаться активным до тех пор, пока сеанс JMS не будет закрыт, поскольку он остался в свободном пуле дольше, чем значение Неиспользованный тайм-аут пула сеансов.

Когда приложение закрывает сессию и соединение в OnMessage, соединение перемещается в пул свободного для повторного использования и сеанс перемещается в свободный пул для повторного использования, экземпляр MQ канала будет не закрыт до соответствующего время ожидания.

Если вы хотите сохранить ваш максимальный канал рассчитывать меньше 200, то вы могли настроить свои Session Pool Maximum Connections) к 1, который в сочетании с активации спецификации и SHARECNV (1) будет Макс из 121 экземпляров канала.

Вы также можете увеличить значение SHARECNV канала, что приведет к делению экземпляров канала на это число.

Возможно, что ваши соединения или сеансы не закрываются должным образом, и у вас есть «утечка».

+0

Извинения за то, что не упоминаются версии WAS и MQ. Я добавил, что в вопросе сейчас. Спасибо за объяснение, это устраняет мои сомнения. Я изменю соединения SHARECNV или сеанса с максимальным подключением и проверю, устранена ли проблема. Еще один вопрос, ссылка, которую вы разделили, также упоминает о настройке свойства SHARECONVALLOWED в заводских условиях или спецификации активации. Это должно присутствовать как для спецификации действия, так и для фабрики соединений или только для одного из них, если я увеличиваю значение SHARECNV. – Neel

+0

Отличный рассказ Джош. Спасибо за это. – Nicholas

+0

@JoshMc Я попробовал эти настройки в уменьшенной версии в Test Env, которая имеет ту же версию WAS и MQ с настройками max серверных сессий, для параметра действия, установленного в 10. максимальное количество подключений в Connection Factory до 10 и максимальный сеанс в сеансовом пуле фабрики подключений до 10. Свойство SHARECNV в канале, установленном в 10, и свойство SHARECONVALLOWED установлено в yes в act spec и Queue Conn Factory. Но после небольшого теста на загрузку одного запроса на секунду в течение 5 минут экземпляры канала пошли до 54, чего не ожидалось в соответствии с расчетами. – Neel