for - La aplicación web Java en tomcat se congela periódicamente

tomcat 9 for windows 64bit

Question

Mi aplicación web Java que ejecuta Tomcat (7.0.28) periódicamente deja de responder. Espero algunas sugerencias de posibles culpables (¿sincronización?), Así como quizás algunas herramientas recomendadas para recopilar más información sobre lo que ocurre durante un bloqueo. Algunos hechos que he acumulado:

• Cuando la aplicación web se congela, tomcat continúa alimentando hilos de solicitud en la aplicación, pero la aplicación no los libera. El grupo de subprocesos se llena hasta el máximo (actualmente 250), y las solicitudes subsiguientes fallan inmediatamente. Durante el funcionamiento normal, nunca hay más de 2 o 3 hilos activos.

• No hay errores ni excepciones de ningún tipo registradas en ninguno de los registros de Tomcat o de la aplicación web cuando ocurre el problema.

• Hacer un "alto" y luego un "inicio" en nuestra aplicación a través de la aplicación web de administración de tomcat resuelve inmediatamente este problema (hasta hoy).

• Últimamente, la frecuencia ha sido dos o tres veces al día, aunque hoy ha sido mucho peor, probablemente 20 veces, y en ocasiones no vuelve a la vida de inmediato.

• El problema ocurre solo durante el horario comercial

• El problema no ocurre en nuestro sistema de etapas

• Cuando se produce el problema, el uso del procesador y la memoria en el servidor permanece plano (y bastante bajo). Tomcat informa mucha memoria libre.

• Tomcat sigue siendo receptivo cuando ocurre el problema. La aplicación web de administración funciona perfectamente, y tomcat continúa enviando solicitudes a nuestra aplicación hasta que se llenen todos los hilos del grupo.

• Nuestro servidor de base de datos sigue siendo receptivo cuando ocurre el problema. Utilizamos el marco Spring para el acceso e inyección de datos.

• El problema generalmente ocurre cuando el uso es alto, pero nunca hay un pico de uso inusualmente alto.

• Historial de problemas: algo similar ocurrió hace un año y medio. Después de muchos cambios en la configuración y el código del servidor, el problema desapareció hasta hace aproximadamente un mes. En las últimas semanas se ha producido con mucha más frecuencia, un promedio de 2 o 3 veces al día, a veces varias veces seguidas.

• Identifiqué algún código de servidor hoy que puede no haber sido seguro para las hebras, y puse una solución para eso, pero el problema todavía está sucediendo (aunque con menos frecuencia). ¿Es este el tipo de problema que puede causar un código inseguro?

ACTUALIZACIÓN: con varias publicaciones que sugieren el agotamiento del conjunto de conexiones de la base de datos, hice algunas búsquedas en esa dirección y encontré esta otra pregunta de Stackoverflow que explica casi todos los problemas que estoy experimentando.

Aparentemente, los valores predeterminados para las conexiones maxActive y maxIdle en la implementación BasicDataSource de Apache son cada uno 8. Además, maxWait se establece en -1, por lo que cuando el grupo se agote y entre una nueva solicitud de conexión, esperará por siempre sin iniciar sesión. tipo de excepción. Todavía voy a esperar a que este problema vuelva a suceder y realizar un volcado de jstack en la JVM para poder analizar esa información, pero parece que este es el problema. Lo único que no explica es por qué la aplicación a veces no se recupera de este problema. Supongo que las solicitudes simplemente se acumulan a veces y una vez que se atrasa nunca pueden ponerse al día.

ACTUALIZACIÓN II: ejecuté un jstack durante un bloqueo y encontré aproximadamente 250 (hilos máximos) de lo siguiente:

"http-nio-443-exec-294" daemon prio=10 tid=0x00002aaabd4ed800 nid=0x5a5d in Object.wait() [0x00000000579e2000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1118)
        - locked <0x0000000743116b30> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
        at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
        at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
        at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:674)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:718)

Para mi ojo inexperto, esto parece bastante concluyente. Parece que el grupo de conexiones de la base de datos ha tocado su límite. Configuré un maxWait de tres segundos sin modificar maxActive y maxIdle solo para asegurarnos de comenzar a ver las excepciones registradas cuando el grupo se llena. Luego estableceré esos valores en algo apropiado y supervisaré.

ACTUALIZACIÓN III: Después de configurar maxWait, comencé a ver estos en mis registros, como se esperaba:

 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
        at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:114)
        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
        at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
        at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)

Establecí maxActive en -1 (infinito) y maxIdle en 10. Voy a monitorear por un tiempo, pero creo que este es el final del problema.

Answer 1

Por experiencia, es posible que desee ver la implementación de su grupo de conexiones de base de datos . Podría ser que su base de datos tenga mucha capacidad, pero el grupo de conexiones de su aplicación está limitado a un pequeño número de conexiones. No puedo recordar los detalles, pero parece recordar que tuve un problema similar, que fue una de las razones por las que BoneCP al uso de BoneCP , que me pareció muy rápido y confiable en las pruebas de carga.

Después de probar la depuración sugerida a continuación, intente aumentar la cantidad de conexiones disponibles en el grupo y vea si eso tiene algún impacto.

Identifiqué algún código de servidor hoy que puede no haber sido seguro para las hebras, y puse una solución para eso, pero el problema todavía está sucediendo (aunque con menos frecuencia). ¿Es este el tipo de problema que puede causar un código inseguro?

Depende de lo que quieras decir con thread-safe. Me parece que su aplicación está causando que los hilos se deadlock . Es posible que desee ejecutar su entorno de producción con la JVM configurada para permitir que un depurador se conecte, y luego usar JVisualVM, JConsole u otra herramienta de creación de perfiles (YourKit es una excelente IMO) para echar un vistazo a los hilos que tiene, y lo que Estoy esperando.