Utilice WebSphere Message Broker Explorer para ver los datos de estadísticas de recursos para los grupos de ejecución en las vistas Recursos de intermediarios y Gráfico de recursos de intermediarios.
También puede ver la recopilación de estadísticas de recursos suscribiéndose al tema sobre el que se publican estadísticas. Para obtener más detalles, consulte Suscripción a informes estadísticos.
Para ver estadísticas de recursos en WebSphere Message Broker Explorer, realice los pasos siguientes.
Muchas herramientas que son específicas de un sistema operativo le ofrecen la cantidad total de memoria que utiliza el grupo de extensión pero no muestran cómo se ha dividido la memoria entre el proceso Java™ y otros procesos en el grupo de ejecución. Buscando en el campo CommittedMemoryInMB, podrá ver cuánta memoria está asignada en estos momentos a JVM. Y si luego busca en el campo MaxMemoryInMB podrá ver la cantidad máxima de memoria que se puede asignar.
Para ver la frecuencia con que JVM realiza la recogida de basura, marque el campo CumulativeNumberOfGCCollections para ver si el porcentaje de recopilaciones va en aumento. La recogida de basura es un proceso normal y, por lo tanto, se supone que se mostrará algún grado. Sin embargo, una recogida de basura excesiva puede afectar al rendimiento.
Para ver si la recogida de basura es excesiva, supervise el valor CumulativeGCTimeInSeconds. Si este valor aumenta en más de dos segundos en cada intervalo de estadísticas de veinte segundos, pruebe a aumentar el tamaño máximo de almacenamiento dinámico de JVM para su grupo de ejecución utilizando el mandato mqsichangeproperties. Es posible que también desee inspeccionar todos los nodos definidos por el usuario Java y los nodos JavaCompute que se incluyen en los flujos de mensajes desplegados para asegurarse de que no crean ni suprimen muchos objetos que se podrían volver a utilizar; las frecuentes supresiones pueden contribuir a una recogida de basura excesiva.
Cambie estos valores de forma gradual y compruebe los resultados para ver los valores óptimos de su entorno.
Un flujo de mensajes analiza los mensajes de entrada y puede crear muchos mensajes de salida. Estos mensajes pueden tener secuencias de bits o árboles de mensajes de gran tamaño. Los analizadores creados para realizar este proceso de mensajes pueden consumir una gran cantidad de memoria. Utilice las estadísticas de Analizadores para determinar si los analizadores de flujos de mensajes están utilizando más memoria de lo esperado. Si es así, considere la posibilidad de desplegar flujos de este tipo en grupos de ejecución independientes o de mejorar el proceso de la API de plugin ESQL o Java para manejar de forma eficiente los mensajes grandes o transformaciones.
Si un flujo de mensajes recibe o intenta grabar un mensaje no válido, es probable que un analizador lo rechace. Utilice las estadísticas de analizadores de mensajes para ver si un flujo de mensajes está rechazando una gran cantidad de mensajes de entrada o salida en comparación con un proceso satisfactorio.
La creación de sockets salientes puede ser una operación costosa y la cantidad de sockets disponibles en un sistema es un recurso finito. Por lo tanto, si se aumenta la reutilización del socket puede mejorar el rendimiento. Si la carga de trabajo es constante y coherente, el valor de TotalSockets indica un período inicial de actividad, que posteriormente se reduce cuando el grupo de ejecución empieza a reutilizar sockets.
Con el transcurso del tiempo, es previsible un aumento constante en el valor de TotalSockets ya que los sockets se cierran tras un período de inactividad o cuando se han utilizado muchas veces.
Si el valor de TotalSockets aumenta significativamente con el tiempo, esta tendencia podría indicar que los sockets salientes no se están reutilizando.
Si sus flujos de mensajes incluyen los nodos HTTPRequest, compruebe que haya establecido la propiedad keepalive (mantener activo) Habilitar el mantenimiento de activado de HTTP/1.1.
Compruebe también si el punto final al que se invoca utiliza sockets mantenidos en actividad.
El valor de TotalMessages indica el grado de ocupación de cada punto final. El valor del registro de resumen le indica cuánta actividad se ha producido en todo el grupo de ejecución.
Los valores de los campos SentMessageSize_* y ReceivedMessageSize_* proporcionan un perfil de los tamaños de mensajes que fluyen a y desde cada punto final.
Si las estadísticas muestran que el número de llamantes en espera de conexiones es grande, y el tiempo de espera está aumentando, considere la posibilidad de aumentar el tamaño de la agrupación utilizando la propiedad MaxConnectionPoolSize del servicio configurable JDBCProvider.
Como alternativa, pruebe a reducir el número de instancias adicionales configuradas para el flujo de mensajes.
La creación de sockets salientes puede ser una operación costosa y la cantidad de sockets disponibles en un sistema es un recurso finito. Por lo tanto, si se aumenta la reutilización del socket puede mejorar el rendimiento. Si la carga de trabajo es constante y coherente, el valor de TotalSockets indica un período inicial de actividad, que posteriormente se reduce cuando el grupo de ejecución empieza a reutilizar sockets.
Con el transcurso del tiempo, es previsible un aumento constante en el valor de TotalSockets ya que los sockets se cierran tras un período de inactividad o cuando se han utilizado muchas veces.
Si el valor de TotalSockets aumenta significativamente con el tiempo, esta tendencia podría indicar que los sockets salientes no se están reutilizando.
Si sus flujos de mensajes incluyen los nodos HTTPRequest, compruebe que haya establecido la propiedad keepalive (mantener activo) Habilitar el mantenimiento de activado de HTTP/1.1.
Compruebe también si el punto final al que se invoca utiliza sockets mantenidos en actividad.