El módulo web o el servidor de aplicaciones detiene el proceso de solicitudes

Si un proceso de servidor de aplicaciones cierra de forma espontánea o si los módulos web dejan de responder a las nuevas solicitudes, es importante determinar rápidamente por qué se está deteniendo. Puede utilizar algunas de las técnicas siguientes para determinar si el problema es un problema del módulo web o es un problema del entorno del servidor de aplicaciones.

Si un proceso de servidor de aplicaciones se cierra de forma espontánea o si sus módulos web del servidor de aplicaciones dejan de responder a solicitudes nuevas:
  • Si es posible, aísle el problema instalando módulos web en servidores diferentes.
  • [AIX Solaris HP-UX Linux Windows]Compruebe en la estructura de directorios del producto si hay un archivo con un nombre como, por ejemplo, javacore[número].txt. Este archivo es un archivo de volcado de la hebra Java™ que crea la JVM si un proceso de servidor de aplicaciones cierra espontáneamente.
  • [z/OS]Si un proceso de servidor de aplicaciones cierra de modo espontáneo, habrá un SDUMP que puede analizar.
  • Utilice Tivoli Performance Viewer para determinar si cualquiera de los recursos del servidor de aplicaciones como, por ejemplo, la pila Java o las conexiones de base de datos, han alcanzado su capacidad máxima. Si existe un problema de recursos, revise el código de la aplicación para determinar la causa posible:
    • Si se están asignando conexiones de base de datos a una solicitud pero no se liberan nunca cuando las solicitudes finalizan su proceso, asegúrese de que el código de la aplicación efectúa una llamada close() en cualquier objeto Connection abierto dentro de un bloque finally{}.
    • Si el número de hebras del motor del servlet que están utilizándose aumenta de forma constante, revise los bloques de códigos sincronizados de la aplicación para ver si es posible que se haya producido alguna condición de bloqueo.
    • Si el tamaño de almacenamiento dinámico de una JVM aumenta de forma constante, revise el código de la aplicación para ver si puede faltar memoria como, por ejemplo, si se producen recopilaciones estáticas (de nivel de clase) que hacen que nunca se ejecute una recogida de basura para los objetos.
  • Habilite la recogida de basura en modalidad verbosa en el servidor de aplicaciones para poder determinar por qué tiene problemas de falta de memoria. Esta característica añade sentencias detalladas acerca de la cantidad de memoria disponible y la memoria que se está utilizando al archivo de registro de errores de la JVM.
    Para habilitar la recogida de basura en modalidad verbosa:
    1. [AIX Solaris HP-UX Linux Windows][IBM i]En la consola administrativa, pulse Servidores > Tipos de servidor > Servidores de aplicaciones nombre_servidor. A continuación, en Infraestructura de servidor, pulse > Java y gestión de procesos > Definición de procesos > Máquina virtual Java y seleccione Recogida de basura verbosa.
    2. [z/OS]En la consola administrativa, pulse Servidores > Tipos de servidor > Servidores de aplicaciones nombre_servidor. A continuación, en la sección Infraestructura del servidor, pulse > Java y gestión de procesos > Definición de proceso > Máquina virtual Java y seleccione Recogida de basura verbosa.
    3. Detenga y reinicie el servidor de aplicaciones.
    4. Periódicamente, consulte en el archivo de registro las sentencias de recogida de basura. Busque sentencias que empiecen por "allocation failure" (error de asignación). Esta serie indica que la necesidad de asignar memoria ha activado una recogida de basura de la JVM ,lo que ha liberado memoria no utilizada. Los errores de asignación son normales y no necesariamente indican la existencia de un problema. No obstante, las sentencias que siguen a la sentencia de error de asignación muestran el número de bytes necesarios y el número de bytes asignados. Si estos bytes necesitan sentencias indican que la JVM continúa asignando más memoria para uso propio o que la JVM no puede asignar tanta memoria como necesita y puede faltar memoria.

    [AIX Solaris HP-UX Linux Windows][IBM i]También puede utilizar Tivoli Performance Viewer para detectar los problemas de falta de memoria:

  • [AIX Solaris HP-UX Linux Windows]Determine si el servidor de aplicaciones se está ejecutando sin memoria. Si determina que al servidor de aplicaciones le falta memoria, es posible que se produzca una de las situaciones siguientes:
    • Hay una pérdida de memoria en el código de la aplicación que se ha de tratar. Para descubrir la causa de la pérdida de memoria, habilite la propiedad RunHProf en la página Máquina virtual de Java de la consola administrativa. Donde nombre_servidor es el nombre del servidor de aplicaciones problemático. Una vez que habilite la propiedad RunHProf debe:
      • Establezca el campo HProf Arguments en un valor similar a depth=20,file=heapdmp.txt. Este valor muestra pilas de excepciones hasta un máximo de 20 niveles y guarda la salida del vuelco de pila en el archivo raíz_servidor_aplicaciones/bin/heapdmp.txt.
      • Guarde los valores.
      • Detenga y reinicie el servidor de aplicaciones.
      • Si es posible, vuelva a crear el caso de ejemplo o acceda al recurso que ha hecho que el proceso del servidor de aplicaciones se cierre de forma espontánea o que los módulos web hayan dejado de responder a solicitudes nuevas. A continuación, detenga el servidor de aplicaciones. Si no puede reproducir el escenario ni acceder al recurso, espere a que se repita el problema y luego detenga el servidor de aplicaciones.
      • Analice el archivo en el que se ha guardado el volcado del almacenamiento dinámico. Por ejemplo, examine el archivo raíz_serv_aplicaciones/bin/heapdmp.txt.
        • Busque la serie, "SITES BEGIN". Se buscará la ubicación de una lista de objetos Java en memoria, que muestra la cantidad de memoria que se les ha asignado.
        • La lista de objetos Java se genera cada vez que ha habido una asignación de memoria en la JVM. Hay un registro de qué tipo de objeto es la instancia que se ha creado en memoria y un identificador de rastreo de una pila de rastreo, enumerado en cualquier lugar del volcado, que muestra el método Java que ha efectuado la asignación.
        • La lista de objetos Java está en orden descendente por número de bytes asignados. Dependiendo de la naturaleza de la falta de memoria, la clase de problema deberá aparecer al principio de la lista, pero este no siempre es el caso. Busque en la lista si aparecen grandes cantidades de memoria o instancias frecuentes de la misma clase. En este último caso, utilice el ID de la columna pila de rastreo para buscar asignaciones repetidas de la misma clase y método.
        • Examine el código fuente indicado en las pilas de rastreo relacionadas para ver si falta memoria.
    • La JVM está utilizando el tamaño máximo del almacenamiento dinámico que se puede utilizar. En esta situación, debe aumentar el valor de tamaño máximo de almacenamiento dinámico para el servidor de aplicaciones si tiene almacenamiento suficiente para hacerlo.
    • El tiempo de ejecución del servidor presenta un problema. Si determina que existe un problema con el tiempo de ejecución del servidor, asegúrese de que ha aplicado todas las actualizaciones de servicio para el producto. Si, después de aplicar todas las actualizaciones de servicio, continúa produciéndose el problema, póngase en contacto con el servicio de soporte de IBM®.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Examine el volcado de hebras para obtener alguna sugerencia:

    La JVM crea un volcado de almacenamiento dinámico siempre que se cierra espontáneamente un proceso del servidor de aplicaciones. También puede forzar una aplicación para crear un volcado de hebra. Después de crear un volcado, puede comprobarlo para obtener alguna sugerencia relacionada con el motivo por el que no se están procesando las nuevas solicitudes.

    Para forzar un volcado de la hebra:

    1. Mediante el indicador de mandatos wsadmin, obtenga un manejador para el servidor de aplicaciones que tiene problemas:
      wsadmin>set jvm
      [$AdminControl completeObjectName
      type=JVM,process=nombre_servidor,*] 

      donde nombre_servidor es el nombre de su servidor.

    2. Genere el volcado de hebras:
      wsadmin>$AdminControl invoke $jvm dumpThreads
      Nota: El mandato dumpThreads crea otros tipos de archivos de vuelco según los valores -Xdumps. La salida del vuelco varía en función de la plataforma y puede incluir archivos principales del sistema, almacenamiento dinámico y vuelcos breves.
    3. [IBM i]Busque un archivo de salida en el directorio raíz_perfil/logs con un nombre similar a javacore.número_trab.usuario_trab.nombre_trab.fecha_hora.txt.
    4. [AIX Solaris HP-UX Linux Windows]Busque un archivo de salida en el directorio raíz de instalación del producto, con un nombre similar a javacore.fecha.hora.ID.txt.

    Después de que la aplicación cree el volcado, puede comprobar las siguientes sugerencias:

    • [AIX Solaris HP-UX Linux Windows]Series de "error" o "exception information" al principio del archivo. Estas series indican la hebra que ha provocado el cierre espontáneo del proceso del servidor de aplicaciones. Estas series no están presentes si ha forzado el volcado.
    • [IBM i]Busque un tamaño de pila actual que sea excesivo. El volcado de hebras muestra información sobre el tamaño de pila Java actual y los valores mínimo y máximo del tamaño de pila.
    • [AIX Solaris HP-UX Linux Windows]Busque en la instantánea de cada hebra del proceso. El vuelco de hebras contiene una instantánea de cada hebra del proceso que comienza por la sección de vuelco de hebra completo ("Full thread dump").
      • Busque las hebras con una descripción que contenga "state:R". Dichas hebras están activas y en ejecución cuando se fuerza el vuelco o, el proceso ha salido.
      • Busque varias hebras en la misma ubicación origen del código de la aplicación Java. Varias hebras de la misma ubicación podrían ser un indicativo de la existencia de una condición de bloqueo (varias hebras esperando en un supervisor) o de un bucle infinito y también puede servirle para identificar dónde reside el problema en el código de la aplicación.
    • [IBM i]Busque en la instantánea de cada hebra del proceso. El vuelco de hebras contiene una instantánea de cada hebra del proceso, comenzando por la sección con la etiqueta "Thread Information".
      • Busque las hebras que están a la espera de bloqueos que mantienen otras hebras.
      • Busque varias hebras en la misma ubicación origen del código de la aplicación Java. Varias hebras de la misma ubicación podrían ser un indicativo de la existencia de una condición de bloqueo (varias hebras esperando en un supervisor) o de un bucle infinito y también puede servirle para identificar dónde reside el problema en el código de la aplicación.

        Es normal que determinados componentes del tiempo de ejecución del producto tenga determinados tipos de hebras en la misma ubicación del código fuente Java. Estos componentes incluyen el contenedor web, el contenedor EJB y la agrupación de hebras del ORB.

El soporte de IBM tiene documentos y herramientas que le pueden ahorrar tiempo en la recopilación de la información necesaria para resolver los problemas. Antes de abrir un informe de problema, consulte la página del servicio de soporte:

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_appdies
File name: rtrb_appdies.html