Escenario: Se producen problemas con el rendimiento, por
ejemplo:
Tiempos de respuesta pobres en el
área de trabajo cuando se desarrollan flujos de
mensajes
Tiempo de respuesta pobre cuando se despliega
Mensajes específicos tardan mucho en procesarse
Pobre rendimiento general o rendimiento que no está
equilibrado
Solución: Las soluciones posibles son:
Acelerar la mensajería persistente de
WebSphere MQ optimizando la E/S (Entrada/Salida)
Acelerar el acceso a las bases de datos optimizando la E/S
Aumentar la memoria del sistema
Utilizar instancias adicionales o varios grupos de
ejecución
Optimizar las sentencias ESQL para un mayor rendimiento
Una buena fuente de información sobre el rendimiento es el
conjunto de informes en WebSphere MQ Family
Category 2 (freeware) SupportPacs, disponibles para descargar desde la
página Web de WebSphere MQ
SupportPacs.
Este tema
contiene consejos para solucionar algunos problemas comunes que pueden
surgir sobre el rendimiento:
Escenario: El sistema se vuelve cada vez más lento.
Explicación: Cuando un proceso finaliza de forma
anómala, se crea una entrada en las
anotaciones de error
locales y es posible que se grabe un
archivo de datos de vuelco en el directorio de anotaciones de errores o en
el directorio de anotaciones de z/OS. Este directorio es ilimitado y, si no borra los archivos que ya no desee,
es posible que el rendimiento del sistema disminuya debido al espacio
significativo que consumen los archivo antiguos de finalización anómala.
Solución: En
Windows, es aconsejable utilizar el
indicador -w del mandato
mqsicreatebroker
para crear el directorio de errores en una partición del disco duro que no contenga WebSphere Message Broker ni Windows.
Se producen problemas de configuración con un gran número de
componentes
Escenario: Se producen problemas de configuración con un
gran número de componentes.
Explicación: Si está ejecutando
WebSphere Message Broker con un gran número de
componentes configurados, la cantidad de memoria que utilizan los
procesos de intermediario (particularmente el MotorFlujoDatos) puede
sobrepasar sus límites de memoria.
En concreto, puede
sobrepasarse el límite del proceso de usuario o puede alcanzarse el límite
del espacio de direcciones. Es posible que se produzcan problemas, por ejemplo, el mensaje
de error BIP2106E, cuando se ejecute un intermediario con:
Un gran número de flujos de mensajes
Varias bases de datos
Mensajes de entrada o salida muy grandes
Solución: Utilice herramientas específicas de su sistema
operativo para comprobar el tamaño máximo del proceso que falla y, a
continuación, compruebe los límites de usuario (si es aplicable) o los
límites de sistema en el tamaño del proceso.
Utilice el mandato ulimit para
comprobar los límites de usuario en sistemas
Linux o
UNIX y auméntelos, si es necesario.
En cada sistema operativo hay un límite estricto para el
tamaño máximo de proceso y, si se
sobrepasa dicho límite, el error es inevitable:
Sistema operativo
Tamaño máximo de proceso
Windows
2 GB
Solaris
Unos 3,75 GB
HP-UX
Unos 3 GB, dependiendo de los valores del kernel
AIX
(sistema de 32 bits)
2 GB
z/OS
2 GB
Aumentar los límites de usuario más allá de estos valores
no producirá ninguna diferencia.
Si los procesos de intermediario normalmente alcanzan estos tamaños,
considere dispersar sus flujos de mensajes entre más grupos de ejecución
para reducir el tamaño de cada uno por debajo de estos límites.
En AIX,
WebSphere Message Broker limita los motores de flujo de
datos a dos segmentos de memoria de 256 MB, es decir, 512 MB. Normalmente
los procesos de MotorFlujoDatos no requieren más de 512 MB del espacio de
direcciones de AIX, de forma que el
archivo ejecutable de MotorFlujoDatos esté enlazado para tener un espacio de
direcciones por omisión de dos segmentos. Sin embargo, es posible ampliar
el tamaño del espacio de direcciones de
AIX disponible para el proceso de
MotorFlujoDatos, aumentando el número de segmentos de memoria de 256 MB
disponibles. Puede poner un parche en MotorFlujoDatos para utilizar más segmentos de
memoria, utilizando el siguiente mandato de shell:
Esto crea una
versión del MotorFlujoDatos que utiliza cuatro segmentos (es decir, 1 GB).
De
forma alternativa,
en AIX 5.1 y superior, puede
alcanzar el mismo resultado utilizando el mandato
ldedit:
ldedit -b maxdata:0x40000000 MotorFlujoDatos
La aplicación del mantenimiento del Fix Pack sustituye el MotorFlujoDatos
ya existente, por lo que si ha utilizado el procedimiento anterior, debe
repetirlo después de la instalación de cada Fix Pack.
La técnica anterior sólo modifica el límite
flexible, no el límite estricto. Si los procesos de intermediario
normalmente alcanzan estos tamaños, considere dispersar sus flujos de
mensajes entre más grupos de ejecución para reducir el tamaño de cada uno
por debajo de estos límites.
Un bucle WHILE en una matriz XML grande tarda mucho en procesarse
Escenario: Un bucle WHILE en una matriz XML grande tarda
mucho en procesarse.
Explicación: Probablemente esté utilizando la función
CARDINALITY() para determinar el tamaño de la matriz en la sentencia WHILE. Esto no es recomendable, porque con matrices grandes, el coste de
determinar el número de elementos es proporcional al tamaño de la matriz. La función CARDINALITY se invoca cada vez que se ejecuta la
sentencia WHILE. Puesto que el mensaje tiene muchos elementos, hay una
actividad general significativa cuando se ejecuta el bucle de esta manera.
Solución: A menos que tenga un mensaje en el que el
número de elementos de la matriz crezca dinámicamente,
determine el tamaño de la matriz antes de entrar el bucle WHILE. Utilice
código parecido al siguiente:
DECLARE i,c INTEGER;
SET i = 1;
SET c=CARDINALITY(OutputRoot.XML.MyMessage.Array[ ]);
WHILE i <= c DO
. . .
. . . proceso del bucle
. . .
END WHILE;
Las llamadas remotas waitForMessages con
WebSphere MQ Everyplace son lentas
Escenario: Las llamadas remotas waitForMessages con
WebSphere MQ Everyplace son lentas.
Explicación: Esto se debe a que una llamada remota
waitForMessages() necesariamente resulta en una acción de sondeo: el
gestor de colas del cliente intenta repetidamente obtener un mensaje
hasta que hay uno disponible en la cola remota o se alcanza
el tiempo de espera.
Solución: Defina una cola de almacenamiento y reenvío en
el gestor de colas del intermediario y una cola de servidor local en el cliente. Esto proporciona un nivel de desacoplamiento que permite seguir
funcionando en el caso de que el gestor de colas del cliente pase a estar
no disponible. De forma alternativa, especifique una cola remota en el
nodo de salida de WebSphere MQ Everyplace de forma que una
llamada GET local sea suficiente en el lado del cliente.
Hay una pérdida de rendimiento para los procedimientos
almacenados
Escenario: Los procedimientos almacenados que no
devuelven conjuntos de resultados no se ejecutan con la misma eficacia que
cuando se utilizan los controladores DataDirect versión 4.1.
Explicación: Los nuevos controladores DataDirect
versión 5 de Oracle ahora utilizan el parámetro de
configuración ProcedureRetResults para permitir que
el controlador devuelva conjuntos de resultados de los procedimientos
almacenados. Este parámetro sólo se aplica a Oracle. Por
omisión, el parámetro se establece en 1 y tiene que ser 1 si utiliza
procedimientos almacenados que devuelven conjuntos de resultados. Cuando
este parámetro se establece en 0, el controlador no devuelve conjuntos de
resultados de los procedimientos almacenados, lo cual puede provocar un
mayor rendimiento.
Solución: Si sus procedimientos almacenados no devuelven
ningún conjunto de resultados, establezca el parámetro
ProcedureRetResults en 0 (cero).