Sugerencias para la resolución de problemas del componente de gestión de carga de trabajo
Si el componente de gestión de carga de trabajo no distribuye correctamente la carga de trabajo entre los servidores de una configuración de varios nodos, utilice las opciones siguientes para aislar el problema.
- Asegúrese de que la carga de trabajo esté distribuida entre los servidores del clúster.
- Resuelva los problemas con la configuración del entorno de Deployment Manager de varios servidores.
- Eliminar los temas de entorno o configuración
Examinar los archivos de anotaciones cronológicas por si hay errores de WLM y códigos menores CORBA
Analizar los datos de PMI
- Solucione el problema o póngase en contacto con el servicio de soporte de IBM
Eliminar los temas de entorno o configuración
- ¿Hay problemas de conexión de red entre los miembros del clúster o servidores de
administración, por ejemplo, entre el gestor de despliegue o los agentes de nodos?
- Si es así, ejecute ping a las máquinas para así asegurarse de que están conectadas correctamente a la red.
- ¿Hay alguna otra actividad en las máquinas en las que están
instalados los servidores que impida que los servidores den servicio a
una solicitud?
Por ejemplo, compruebe el uso del procesador según la medición del Gestor de Tareas,
el ID del procesador, o cualquier otra herramienta externa para ver si:
- No es el rendimiento esperado o si es irregular en lugar de constante.
- Muestra que recientemente se ha añadido, instalado o actualizado un miembro del clúster que no está utilizándose.
- ¿Están ejecutándose todos los servidores que ha iniciado en cada nodo o se han detenido algunos?
- ¿Están todas las aplicaciones instaladas en funcionamiento?
- Si el problema está relacionado con la distribución de la carga de trabajo en enterprise beans de persistencia gestionada por contenedor (CMP) o de persistencia gestionada por bean (BMP), ¿ha configurado los proveedores de JDBC y el origen de datos JDBC en cada servidor?
Si sufre problemas de gestión de la carga de trabajo relacionados con las solicitudes HTTP como, por ejemplo, que no todos los miembros del clúster están dando servicio a las solicitudes HTTP, tenga en cuenta que el plug-in HTTP equilibra la carga entre todos los servidores definidos en la lista PrimaryServers si no se ha establecido la afinidad. Si no tiene definida una lista de PrimaryServers, entonces la carga del plug-in se equilibra entre todos los servidores que estén definidos en el clúster si no se ha establecido la afinidad. Si se ha establecido la afinidad, el plug-in deberá ir directamente a dicho servidor para todas las solicitudes.
- ¿Se han establecido los pesos en los valores permitidos?
- Para el clúster en cuestión, inicie la sesión en la consola administrativa y:
- Seleccione .
- Seleccione el clúster de la lista.
- Seleccione Miembros del clúster.
- Para cada servidor del clúster, pulse nombre_servidor y anote el peso del servidor asignado.
- Asegúrese de que los pesos estén dentro del rango válido de 0-20. Si un servidor tiene un peso de 0, no se dirigen solicitudes a éste. Los pesos superiores a 20 se tratan como 0.
- Para el clúster en cuestión, inicie la sesión en la consola administrativa y:
el resto de este artículo trata solamente del balance de cargas de trabajo de enterprise beans. Para obtener más ayuda acerca de cómo diagnosticar los problemas de distribución de solicitudes web (HTTP), consulte los temas "Sugerencias para la resolución de problemas del plug-in del servidor web" y "El recurso web no aparece".
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Examinar los archivos de anotaciones cronológicas por si hay errores de WLM y códigos menores CORBA
- Un servidor que se ha marcado como inutilizable más de una vez y continúa siendo inutilizable.
- Todos los servidores de un clúster se han marcado como en mal estado y continúan siendo inutilizables.
Un LSD (Location Service Daemon) se ha marcado como inutilizable más de una vez y continúa siendo inutilizable.
Para hacerlo, utilice el analizador de registros cronológicos y de rastreo para abrir los registros cronológicos de servicio (activity.log) en los servidores afectados y busque las entradas siguientes:
Para hacerlo, abra las anotaciones cronológicas de
servicio de los servidores afectados y consulte las entradas siguientes:
- WWLM0061W: Se ha producido un error al enviar una solicitud al miembro del
clúster miembro y dicho miembro se ha marcado como inutilizable para
solicitudes futuras al clúster clúster.Nota: no es nada extraño que un servidor se marque como inutilizable. Es posible que el servidor se haya marcado como inutilizable debido a motivos operativos normales como, por ejemplo, que se esté ejecutando un inicio escalonado mientras en el servidor continúa habiendo una carga procedente de un cliente.También es normal para obtener muchos mensajes de aviso WWLM0061W para un miembro casi simultáneamente. Normalmente hay solicitudes en proceso en varias hebras y después de que el miembro se marque como no disponible es probable que las hebras que tienen como destino dicho miembro reciban dicho mensaje de aviso.
- WWLM0062W: Se ha producido un error al enviar una solicitud al miembro del clúster miembro y dicho miembro se ha marcado una o más veces como inutilizable para solicitudes futuras al clúster clúster.
- WWLM0063W: Se ha producido un error al intentar utilizar LSD nombre_LSD para resolver una referencia a objeto para el clúster clúster y se ha marcado como inutilizable para solicitudes futuras a dicho clúster.
- WWLM0064W: Se han producido errores al intentar enviar una solicitud a todos los miembros del clúster clúster y todos los miembros del clúster se han marcado como inutilizables para solicitudes futuras a dicho clúster.
- WWLM0065W: Se ha producido un error al intentar actualizar un miembro del clúster servidor en el clúster clúster, ya que no se ha podido acceder al mismo desde el gestor de despliegue.
- WWLM0067W: El cliente está enviando señales para volver a intentar la solicitud. No e puede volver a intentar de forma transparente una solicitud de servidor
mediante WLM debido a la excepción:{0}
Al intentar dar servicio a una solicitud, WLM ha encontrado una condición que es posible que no permita que la solicitud se vuelva a enviar de forma transparente. La excepción de origen se está capturando y se está generando para el cliente un CORBA.TRANSIENT nuevo con el código menor 0x49421042 (SERVER_SIGNAL_RETRY).
- Una posible respuesta del usuario como, por ejemplo, cambiar un valor de configuración.
- Excepciones de clases básicas que pueden indicar un defecto del producto.
Es posible que también vea excepciones con "CORBA" como parte del nombre de excepción, ya que WLM utiliza la arquitectura CORBA (Common Object Request Broker Architecture) para las comunicaciones entre procesos. Busque una sentencia en la pila de excepciones para especificar un "código menor". Estos códigos indican la razón específica por la que no se ha podido completar una llamada de CORBA o una respuesta. Los códigos menores de WLM caen dentro del rango de 0x4921040 - 0x492104F. Para obtener una descripción de los códigos menores relacionados con WLM, consulte el tema "Referencia: documentación de la API generada" del paquete y la clase com.ibm.websphere.wlm.WsCorbaMinorCodes.
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Analizar los datos de PMI
La finalidad de analizar los datos de PMI es comprender la carga de trabajo que llega a cada miembro de un clúster Los datos de cualquier miembro del clúster solamente resultan útiles dentro del contexto de los datos de todos los miembros del clúster.
Utilice Tivoli Performance Viewer para comprobar que, según los pesos asignados a los miembros del clúster (los pesos de estado constante), cada servidor obtiene la proporción correcta de solicitudes.
- Seleccione Colección de datos en la vista de árbol. Los servidores que no tengan PMI habilitado, aparecen sombreados.
- Para cada servidor de datos en el que desee recopilar datos, pulse Especificar...
- Ahora puede habilitar la métrica. Establezca el nivel de supervisión como bajo en el panel Valores de supervisión del rendimiento.
- Pulse Aceptar
- Debe pulsar Aplicar para guardar los cambios realizados.
La métrica WLM PMI se puede ver por cada servidor. En Tivoli Performance Viewer, seleccione
. De forma predeterminada, los datos aparecen sin formato en una tabla, recopilados cada 10 segundos, como valor de suma. También puede elegir ver los datos como diferenciales o cadencias, añadir o eliminar columnas, borrar el almacenamiento intermedio, restablecer la métrica a cero y cambiar la cadencia de recopilación y el tamaño del almacenamiento intermedio.Después de obtener los datos de PMI, debe calcular el porcentaje de numIncomingRequests para cada miembro del clúster en relación con el total de numIncomingRequests de todos los miembros del clúster. Al comparar este valor de porcentaje con el porcentaje de los pesos dirigidos a cada miembro del clúster se obtiene una visión inicial del balance de cargas de trabajo dirigida a cada miembro de un clúster.
Además del valor de numIncomingRequests, hay otros valores que muestran cómo se equilibra la carga de trabajo entre los miembros de un clúster: numincomingStrongAffinityRequests y numIncomingNonWLMObjectRequests. Estos dos valores muestran el número de solicitudes dirigidas a un miembro específico de un clúster al que solamente puede dar servicio dicho miembro.
- Server1 = 5
- Server2 = 3
- Server3 = 2
- % routed to Server1 = weight1 / (weight1+weight2+weight3) = 5/10 ó 50%
- % routed to Server2 = weight2 / (weight1+weight2+weight3) = 3/10 ó 30%
- % routed to Server3 = weight3 / (weight1+weight2+weight3) = 2/10 ó 20%
Ahora supongamos que no hay solicitudes de entrada con una afinidad fuerte ni hay solicitudes de objetos que no sean de WLM.
- numIncomingRequestsServer1 = 390
- numIncomingRequestsServer2 = 237
- numIncomingRequestsServer3 = 157
De este modo, el número total de solicitudes de entrada al clúster es: numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784
numincomingStrongAffinityRequests = 0
numIncomingNonWLMObjectRequests = 0
- % (actual) routed to Server1 = 390 / 784 = 49,8%
- % (actual) routed to Server2 = 237 / 784 = 30,2%
- % (actual) routed to Server3 = 157 / 784 = 20,0%
- Server1 = 5
- Server2 = 3
- Server3 = 2
- % routed to Server1 = weight1 / (weight1+weight2+weight3) = 5/15 ó 1/3 de las solicitudes
- % routed to Server2 = weight2 / (weight1+weight2+weight3) = 5/15 ó 1/3 de las solicitudes.
- % routed to Server3 = weight3 / (weight1+weight2+weight3) = 5/15 ó 1/3 de las solicitudes.
- numIncomingRequestsServer1 = 1236
- numIncomingRequestsServer2 = 1225
- numIncomingRequestsServer3 = 1230
- numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
- numincomingStrongAffinityRequests = 445 y el total de las 445 solicitudes van dirigidas a Server1.
- numIncomingNonWLMObjectRequests = 0.
- % (actual) routed to Server1 = 1236 / 3691= 33.49%
- % (actual) routed to Server2 = 1225 / 3691= 33.19%
- % (actual) routed to Server3 = 1230 / 3691= 33.32%
No obstante, la correcta interpretación de estos datos es que el direccionamiento de las solicitudes no se ha equilibrado correctamente porque el servidor Server1 tenía varios centenares de solicitudes de afinidad fuerte. WLM intenta compensar las solicitudes de afinidad fuerte directamente a 1 o más servidores distribuyendo las nuevas solicitudes de entrada de forma preferencial a los servidores que no están participando en la afinidad transaccional para compensar a aquellos servidores que participan en transacciones. En el caso de las solicitudes de entrada con afinidad fuerte y de solicitudes de objeto que no son de WLM, el análisis sería análogo en este caso.
Si después de analizar los datos de PMI y tener en cuenta la afinidad entre transacciones y las solicitudes de objetos que no son de WLM, el porcentaje de las solicitudes de entrada reales al servidor de un clúster no reflejan los pesos asignados, significa que las solicitudes no se están equilibrando correctamente. Si este es el caso, se le recomienda que repita los pasos para eliminar los problemas del entorno y de la configuración y examine los archivos de registros antes de continuar.
Solucione el problema o póngase en contacto con el servicio de soporte de IBM
Si los datos PMI o las anotaciones cronológicas del cliente
indican que se ha producido un error en WLM, recopile la información siguiente y
póngase en contacto con el servicio de soporte de IBM.
Si las anotaciones cronológicas del cliente indican que se ha producido un error en WLM, recopile la información siguiente y póngase en contacto con el servicio de soporte de IBM.
- Una descripción detallada del entorno.
- Una descripción de los síntomas.
Los archivos SystemOut.logs y SystemErr.logs para todos los servidores del clúster.
Los archivos de registros cronológicos de servidor de todos los servidores del clúster.
El archivo activity.log.
Los archivo de registro cronológico de captura de datos en primer error.
Los valores de PMI.
- Una descripción de lo que está intentando realizar el cliente y una descripción del cliente. Por ejemplo, 1 hebra, varias hebras, un servlet, el cliente J2EE, etc.
Si ninguno de estos pasos resuelve el problema, compruebe si el problema se ha identificado y está documentado utilizando los enlaces del tema "Diagnóstico y solución de problemas: recursos de aprendizaje". Si no encuentra ningún problema que se asemeje al suyo o si la información proporcionada no resuelve el problema, póngase en contacto con el servicio de soporte de IBM para obtener más ayuda.
Si no encuentra su problema, póngase en contacto con el
soporte de IBM.
Para
obtener la información actual disponible del servicio de soporte de IBM sobre problemas
conocidos y su resolución, consulte la página de IBM Support. Consulte también esta página antes de abrir un PMR, ya que
contiene documentos que pueden ahorrarle tiempo en la recopilación de la información
necesaria para resolver un problema.
Para obtener información actual del servicio de
soporte de IBM sobre problemas conocidos y su resolución, consulte la
página Software de IBM i. Consulte también esta página antes de abrir un PMR, ya que
contiene información acerca de los documentos que tiene que recopilar y enviar a IBM para recibir ayuda relacionada con un problema.