Escenario: Se producen problemas con el rendimiento, por
ejemplo:
Tiempos de respuesta lentos en el
entorno de trabajo cuando se desarrollan flujos de
mensajes
Tiempo de respuesta lento durante el despliegue
Mensajes específicos que tardan mucho en procesarse
Rendimiento general pobre 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 mejor 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.
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 parámetro -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 Fixpack sustituye el MotorFlujoDatos
ya existente, por lo que si ha utilizado el procedimiento anterior,
repítalo después de la instalación de cada Fixpack.
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 del siguiente ejemplo:
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).
Experimenta un rendimiento bajo en el
entorno de trabajo cuando trabaja con proyectos grandes
Escenario: Experimenta un rendimiento bajo en el
entorno de trabajo cuando trabaja con proyectos
grandes o complejos.
Explicación: Si experimenta un rendimiento bajo a causa de
cambios frecuentes en proyectos como, por ejemplo, la adición y supresión
de proyectos, o la utilización de
Proyecto > Limpiar,
el motivo es que las actualizaciones completas de proyectos utilizan
grandes cantidades de memoria debido al tamaño, número y conexiones entre
archivos.
Solución: Aumente la memoria del sistema.
El valor del campo PutTime del que informa WebSphere MQ en z/OS, y otra horas o indicaciones de la
hora son incoherentes
Escenario: El valor del campo PutTime del que
informa WebSphere MQ en z/OS, y otras horas o indicaciones de la
hora son incoherentes.
Se detecta una diferencia de aproximadamente 20 segundos en:
rastreos (incluido el que se obtiene del nodo Trace)
la indicación de la hora MQPUTTIME de la cabecera MQMD del mensaje
indicaciones de la hora obtenidas de ESQL (por ejemplo, en un nodo
Compute)
Explicación: WebSphere Message Broker
informa de la hora utilizando UTC (Tiempo Universal Coordinado), que no
tiene en cuenta los segundos intercalares. Sin embargo, en
z/OS, el valor putTime del mensaje del que
informa WebSphere MQ en la cabecera MQMD de
un mensaje sí tiene en cuenta los
segundos intercalares, utilizando el valor especificado para el
número de segundos intercalares en el campo CVT.
Esta
incoherencia puede provocar:
problemas al depurar
problemas con flujos de mensajes si utiliza indicaciones de la hora
para controlar el flujo de los mensajes
información errónea
Solución: Establezca el campo CVT de manera que concuerde
con los segundos intercalares de UTC. De forma
alternativa, añada un desplazamiento para ajustar la lectura de una indicación
de la hora z/OS. Por ejemplo, añada
20 segundos cuando intente obtener CURRENT_TIME en ESQL.