Problema de recuento de conexiones altas de WebSphere MQ
Según nuestra configuración, tenemos la versión WAS es 8.5.5.1, IBM MQ versión 7.5.0.3. Estamos utilizando 2 canales para conectarnos a WMQ, uno con MAXINST configurado en 250 y otro con 500. SHARECNV está configurado en 10 para ambos. Ahora tenemos un límite superior de hacer un máximo de 1600 conexiones en un gestor de colas, pero terminamos cruzando ese límite después de 3-4 días de funcionamiento continuo del servidor WAS.
Quiero entender cómo los parámetros del lado WAS afectan este recuento. Estamos utilizando Queue Connection Factory y Act Spec para hacer las conexiones y tenemos 23 de cada una de ellas. De estos para 22, la configuración en Act Spec y QCF se mantiene predeterminada, como sesiones de servidor máximas = 10, conexión máxima en grupo de conexiones = 10, sesiones máximas en grupo de sesiones establecidas en 10. Estos servicios tienen tps bastante bajos de alrededor de 15-20 solicitud por minuto. Los 22 usan el mismo canal para conectarse al gestor de colas con MAXINST configurado en 250. 1 obtiene una carga bastante alta con un pico de 80 solicitudes por segundo (aproximadamente 40 por servidor) para las cuales sesiones de servidor máximo = 40, conexión máxima en el grupo de conexiones = 40, el número máximo de sesiones en el grupo de sesiones se establece en 10. Los valores de Tiempo de espera de conexión, Tiempo de cosecha, Tiempo de espera no utilizado y Tiempo de espera antiguo se mantienen predeterminados para todos.
Con esta configuración, terminamos realizando alrededor de 1200 conexiones en el canal utilizado por 22 servicios y alrededor de 500 para el otro canal después de 2-3 días de funcionamiento continuo. Estos se acumulan durante un período de tiempo. Ahora quiero ajustar esta configuración para que no terminemos de cruzar el límite de conteo de conexiones y tampoco terminemos sin tener conexiones disponibles. Entonces tengo algunas preguntas:
Cuál es una mejor opción desde el punto de vista del rendimiento: reducir las conexiones máximas en el grupo de conexiones o las sesiones máximas en el grupo de sesiones. Cuáles deberían ser los valores ideales para la carga mencionada anteriormente.
¿Cuál debería ser el valor ideal para el tiempo de espera no utilizado para el grupo de conexiones y el grupo de sesiones que se establece en 30 minutos de forma predeterminada? Si lo reducimos a 5 minutos, ¿qué implicaciones podría tener en el rendimiento del fracaso para obtener las conexiones?
¿Hay alguna configuración que se pueda hacer en el lado WMQ para que las conexiones inactivas / no utilizadas estén cerradas o esto solo puede ocurrir desde el lado del cliente?
El valor del parámetro DISCINT se establece en cero y HBINT en 300. Cuál debería ser el valor ideal.
Ejecuté debajo del comando para ver las conexiones
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
Puedo ver mucha conexión en Ninguno y estado suspendido que no tiene ningún OBJNAME u OBJTYPE asociado. He intentado simular el problema en Test y sucede lo mismo y estas conexiones siguen aumentando a medida que seguimos respondiendo a las solicitudes. ¿Alguien puede decirme por qué se crean estas conexiones? También parece que estas conexiones nunca serán utilizadas por la aplicación.
Así es como se hacen y cierran las conexiones en la aplicación: tenemos una clase de bean abstrack que se extiende por todos los MDB
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue") })
public class TrackBeanV2 extends AbstractServiceBean implements MessageListener {//code}
El bean abstrack maneja la creación y el cierre de conexiones de la siguiente manera:
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);
}
No he agregado otros métodos de la clase que reúnen / desarman y otras cosas.