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.

Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.

Eliminar los temas de entorno o configuración

Determine si los servidores pueden dar servicio a las aplicaciones para las que se han habilitado. Identifique el clúster que tiene el problema.
  • ¿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.

Para los problemas de gestión de la carga de trabajo relacionados con las solicitudes de enterprise beans como, por ejemplo, si no todos los miembros de un clúster dan servicio a las solicitudes de enterprise beans:
  • ¿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:
      1. Seleccione Servidores > Clústeres > Clústeres de servidores de aplicaciones de WebSphere.
      2. Seleccione el clúster de la lista.
      3. Seleccione Miembros del clúster.
      4. 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.

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][AIX Solaris HP-UX Linux Windows]

Examinar los archivos de anotaciones cronológicas por si hay errores de WLM y códigos menores CORBA

Si continúa encontrando problemas con la gestión de carga de trabajo de los enterprise beans, el paso siguiente es comprobar en las anotaciones cronológicas de actividad las entradas que muestran:
  • 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.
  • [z/OS]Un LSD (Location Service Daemon) se ha marcado como inutilizable más de una vez y continúa siendo inutilizable.

[IBM i][AIX Solaris HP-UX Linux Windows]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:

[z/OS]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).

Si encuentra cualquiera de estos avisos, siga las respuestas del usuario que se proporcionan en las anotaciones cronológicas. Si después de la siguiente respuesta de usuario, continúa recibiendo los mensajes de aviso, consulte cualquier otro mensaje de error o de aviso del analizador de anotaciones cronológicas y de rastreo para los servidores afectados y busque:
  • 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][AIX Solaris HP-UX Linux Windows]

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.

Para utilizar Tivoli Performance Viewer con el fin de capturar métricas PMI, en la navegación del producto Tivoli Performance Viewer realice las siguientes acciones:
  1. Seleccione Colección de datos en la vista de árbol. Los servidores que no tengan PMI habilitado, aparecen sombreados.
  2. Para cada servidor de datos en el que desee recopilar datos, pulse Especificar...
  3. Ahora puede habilitar la métrica. Establezca el nivel de supervisión como bajo en el panel Valores de supervisión del rendimiento.
  4. Pulse Aceptar
  5. Debe pulsar Aplicar para guardar los cambios realizados.

La métrica WLM PMI se puede ver por cada servidor. En Tivoli Performance Viewer, seleccione Nodo > Servidor > Gestión de la carga de trabajo > Servidor/Cliente. 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.

Por ejemplo, suponga que hay un clúster de 3 servidores. Los pesos siguientes se asignan a cada uno de estos tres servidores:
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
Permita que el clúster de servidores comience a dar servicio a las solicitudes y espere a que el sistema esté en un estado nivelado, es decir, que el número de solicitudes de entrada al clúster sea igual al número de respuestas procedentes de los servidores. En esta situación, se espera que el valor de porcentaje de las solicitudes dirigidas a cada servidor sea:
  • % 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.

En este caso, supongamos que los valores de PMI recopilados muestran que el número de solicitudes de entrada para cada servidor es:
  • 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

¿Podemos tomar una decisión basándonos en estos datos si WLM está equilibrando correctamente las solicitudes de entrada entre los servidores del clúster? Dado que no hay solicitudes con una afinidad fuerte, la pregunta que debemos responder es, ¿las solicitudes se encuentran en las proporciones que esperamos según los pesos asignados? El cálculo que responde a la pregunta es directo:
  • % (actual) routed to Server1 = 390 / 784 = 49,8%
  • % (actual) routed to Server2 = 237 / 784 = 30,2%
  • % (actual) routed to Server3 = 157 / 784 = 20,0%
Por lo tanto, WLM se está comportando tal y como se ha diseñado, ya que los datos los que se esperaban según los pesos asignados a los servidores.
Por ejemplo, suponga que hay un clúster de 3 servidores. Y que se han asignado los pesos siguientes a cada uno de estos tres servidores:
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
Permita que el clúster de servidores comience a dar servicio a las solicitudes y espere a que el sistema esté en un estado nivelado, es decir, que el número de solicitudes de entrada al clúster sea igual al número de respuestas procedentes de los servidores. En esta situación, se espera que el valor de porcentaje de las solicitudes dirigidas a los servidores 1-3 sea:
  • % 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.
En este caso, supongamos que los valores de PMI recopilados muestran que el número de solicitudes de entrada para cada servidor es:
  • numIncomingRequestsServer1 = 1236
  • numIncomingRequestsServer2 = 1225
  • numIncomingRequestsServer3 = 1230
De este modo, el número total de solicitudes de entrada al clúster:
  • numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
  • numincomingStrongAffinityRequests = 445 y el total de las 445 solicitudes van dirigidas a Server1.
  • numIncomingNonWLMObjectRequests = 0.
En este caso, observamos que el número de solicitudes no se ha distribuido uniformemente entre los tres servidores, como se esperaba. Sino que la distribución es:
  • % (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

[IBM i][AIX Solaris HP-UX Linux Windows]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.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Los archivos SystemOut.logs y SystemErr.logs para todos los servidores del clúster.
  • [z/OS]Los archivos de registros cronológicos de servidor de todos los servidores del clúster.
  • [IBM i][AIX Solaris HP-UX Linux Windows]El archivo activity.log.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Los archivo de registro cronológico de captura de datos en primer error.
  • [IBM i][AIX Solaris HP-UX Linux Windows]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.

[AIX Solaris HP-UX Linux Windows][z/OS]Si no encuentra su problema, póngase en contacto con el soporte de IBM.

[AIX Solaris HP-UX Linux Windows]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.

[IBM i]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.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_wlmcomp
File name: rtrb_wlmcomp.html