2011-04-11 29 views
5

Tenemos una aplicación que pierde un poco de memoria, un poco siendo un eufemismo.Apache Tomcat Request Threads

Estoy usando jvisualvm para tratar de encontrar lo que está causando el problema.

veo el número de hilos crecer un poco en las discusiones que empiezan con el nombre: http-8080- ejemplo: http: 8080-42

Mi primera suposición es que cada uno de esos hilos es una solicitud exitosa del cliente, ya que cada solicitud del cliente se maneja en su propio hilo.

Mi problema es que esos hilos han estado funcionando durante largos períodos de tiempo (Hasta ahora 10 minutos).

Mi pregunta es la siguiente:

¿Es mi suposición correcta? Si es así, ¿por qué los hilos se ejecutan durante tanto tiempo? Sin duda, todavía no puede estar ocupado atendiendo la solicitud de los clientes?

+0

¿Es posible que esos hilos sean hilos de sesión? – Koekiebox

Respuesta

6

Tomcat siempre tiene un número de espera hebras HTTP, por ejemplo, si nos fijamos en la configuración de conector predeterminado:

<Connector port="80" maxHttpHeaderSize="8192" 
       maxThreads="150" minSpareThreads="25" maxSpareThreads="75" 
       enableLookups="false" redirectPort="8443" acceptCount="100" 
       connectionTimeout="20000" disableUploadTimeout="true" /> 

podemos ver que siempre debe haber al menos 25 hilos de vivir, pero a la espera de conexiones (hasta el límite de maxThreads). Esto está controlado por los atributos min y maxSpareThreads.

¿Qué JVisual VM indica que el hilo está esperando o bloqueado en un recurso, etc.?

+0

Todos esos hilos se encuentran en un estado de espera: "http-8080-24" - Tema t @ 70 java.lang.Thread.State: ESPERA \t en java.lang.Object.wait (Nativo Método) \t - esperando en <96c084> (a org.apache.tomcat.util.net.JIoEndpoint $ Worker) \t en java.lang.Object.wait (Object.java:485) \t en org.apache.tomcat.util.net.JIoEndpoint $ Worker.await (JIoEndpoint.java:414) \t en org.apache.tomcat.util.net.JIoEndpoint $ Worker.run (JIoEndpoint.java:440) \t en java.lang.Thread.run (Thread.java) : 619) Sincronizadores de dispositivos bloqueados: \t - Ninguno – Koekiebox

+0

Sí, están esperando más conexiones, perfectamente esperadas (y comportamiento deseable). :) – Mikaveli

1

En general, los servidores de aplicaciones precrearán varios subprocesos. El servidor de la aplicación no solo los creará, sino que mantendrá los hilos alrededor. Esto se conoce como un grupo de subprocesos. El servidor tomará una solicitud y la enviará a un hilo, y cuando esa solicitud se complete, el servidor enviará una nueva solicitud a ese hilo.

La sobrecarga de creación de subprocesos es bastante costosa, por lo que el manejo de muchas solicitudes se beneficia enormemente del intercambio de subprocesos. Para responder a su pregunta, el envío de subprocesos creados por el servidor (suponiendo que no se produzcan errores graves en el tiempo de ejecución) durará toda la vida del servidor.

En cuanto a lo que está viendo, si ve que se inician muchos subprocesos, entonces otra parte de la aplicación puede estar bifurcando hilos, que es un problema completamente distinto.

Es importante saber que su servidor tomcat no debería crear subprocesos nuevos para cada solicitud (de nuevo en términos generales) debería volver a utilizar subprocesos.

2

Compruebe las configuraciones del conector tomcat. Preste atención a maxThreads y a otra configuración de grupo de subprocesos. Un error común es simplemente aumentar maxThreads sin realmente "Tuning". Si configura un grupo innecesariamente grande, dará lugar a un montón de subprocesos inactivos. Esto no servirá de nada.

Aunque es obvio, solo para el registro, los hilos TIMED_WAITING agotarán el tiempo de espera, y los hilos WAITING se limitarán a notify() o notifyAll().