Consumo memoria Usada! Proyecto en producción!

[Jordi Durany，修改在10 年前。]

Antes de nada, como siempre por la gente que puede dedicar unos minutos a ayudar a los demas. Acabamos de poner nuestro proyecto en real y tenemos un problema SERIO!
Nuestro sistema, esta basado en un glassfish(3.1.2) en el que hemos instalado liferay(6.1.2 CE GA3) usando una BD de oracle.
Hemos desarrollado unos portlets mediante JSF(2.0) + JPA y EJB(3.1) (no hemos usado hibernate) que utiliza una tercera conexión. Tenemos una BD con el esquema de liferay y otra BD con el esquema que tiene datos para la aplicación que hemos creado.
La version de java que tenemos es el jdk 1.6.0_45.
El problema que tenemos es que al usar nuestra aplicación integrada liferay, al usar nuestros portlets la memoria usada (si la miramos desde el administrador de liferay poco a poco va creciendo, y no se limpia la pila entiendo. En cambio si solo usamos liferay vemos que si se va limpiando la pila.
Los parametros que hemos usado de memoria en liferay son:
-xms:2048m
-xmx:2048m
-MaxPermsize:512
Alguien tiene una idea de que puede provocar que el uso de nuestra aplicación haga que la memoria usada poco a poco (al cabo de horas de uso) no se recupere?
He probado de lanzar el garbage colector des de el mismo liferay, pero la memoria usada no se recupera.

[Juan Gonzalez，修改在10 年前。]

Hola Jordi,

las variables que pueden causar dicho memory leak son bastantes.

Pero para empezar, ¿cómo has desarrollado los portlets JSF? ¿Usas Liferay Faces? ¿Qué versión?

¿Tienes más portlets propios que no sean de tipo JSF?

¿Usas el portal en cluster?

[Beatriz Sánchez Pérez，修改在10 年前。]

Hola,

A nosotros nos pasa lo mismo, cuando reiniciamos el servidor tiene más de un 40% de memoria libre (tiene 6Gb en total), pero conforme va pasando el tiempo se incrementa el Old Heap Space sin poder liberarla, tiene pinta de ser una fuga de memoria de la aplicación o algún tipo de mal configuración de la misma, pero no conseguimos detectar donde está el problema.

El error que sale es

17:08:49,525 INFO [stdout] (ajp--127.0.0.1-8009-2) Communications link failure due to underlying exception:
17:08:59,958 INFO [stdout] (ajp--127.0.0.1-8009-2)
17:08:59,959 INFO [stdout] (ajp--127.0.0.1-8009-2) ** BEGIN NESTED EXCEPTION **
17:08:59,959 INFO [stdout] (ajp--127.0.0.1-8009-2)
17:08:59,959 INFO [stdout] (ajp--127.0.0.1-8009-2) com.mysql.jdbc.CommunicationsException
17:08:59,959 INFO [stdout] (ajp--127.0.0.1-8009-2) MESSAGE: Communications link failure due to underlying exception:
17:08:59,960 INFO [stdout] (ajp--127.0.0.1-8009-2)
17:08:59,960 INFO [stdout] (ajp--127.0.0.1-8009-2) ** BEGIN NESTED EXCEPTION **
17:08:59,960 INFO [stdout] (ajp--127.0.0.1-8009-2)
17:08:59,960 INFO [stdout] (ajp--127.0.0.1-8009-2) java.io.EOFException
17:08:59,961 INFO [stdout] (ajp--127.0.0.1-8009-2) MESSAGE: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
17:08:59,965 INFO [stdout] (ajp--127.0.0.1-8009-2)
17:09:10,737 INFO [stdout] (ajp--127.0.0.1-8009-2) STACKTRACE:
17:09:10,737 INFO [stdout] (ajp--127.0.0.1-8009-2)
17:09:10,738 INFO [stdout] (ajp--127.0.0.1-8009-2) java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection

Las especificaciones de la máquina virtual son las siguientes
2 Virtual CPU con 6 Gigas de RAM.
32 GB de disco duro.

Las especificaciones del sistema son
RedHat ES 6 64 bits
Liferay Portal Community Edition 6.1.1 CE GA2 (Paton / Build 6101 / July 31, 2012)
JBoss 7.1.1
MySQL de base de datos

Por otra parte la configuración de JAVA_OPTS es
JAVA_OPTS="$JAVA_OPTS -Xms2048m -Xmx2048m -XX:MaxPermSize=768m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XXarallelGCThreads=2"

La configuración relacionada con el pool de conexiones es la siguiente
jdbc.default.liferay.pool.provider=c3po
jdbc.default.maxPoolSize=100
jdbc.default.maxIdleTime=360

Tenemos un total de 44 entre portlets y hooks instalados. No usamos Liferay Faces para el desarrollo de portlets.

Cualquier ayuda será bien recibida.

Muchas gracias de antemano por vuestro tiempo.

Un saludo, Bea.

[Jordi Durany，修改在10 年前。]

Buenas,

hemos solucionado el problema.

Lo hemos solucionado corrigiendo el tiempo de las sesiones de jsf. Antes teníamos el tiempo demasiado alto, y el servidor no podía matar esas sesiones antes que el servidor se saturase.

[Juan Gonzalez，修改在10 年前。]

Hola Jordi,

me alegro que hayáis podido dar con el problema.

Otra cosa, muchas aplicaciones JSF hacen un uso excesivo de datos en sesión (listados de datatable, etc). También te recomendaría que lo revisárais ya que en principio, a menos que haya muchos usuarios conectados, el tiempo de sesión no debería de ser un problema tan importante.

[Beatriz Sánchez Pérez，修改在10 年前。]

¿Qué tiempo habéis puesto?
¿Puede ser por la máquina que tenemos?

A nosotros se nos cae cada día.

[Juan Gonzalez，修改在10 年前。]

Hola Beatriz,

por lo general, cuantos menos portlets tengáis en ejecución, menos memoria consumirá. Esto también es aplicable a los WAR que tengáis desplegados.

Podríais probar a unificar vuestros portlets/hooks en el mínimo número de WAR posibles y ver cómo evoluciona.

[Beatriz Sánchez Pérez，修改在10 年前。]

Antes de nada, gracias por contestar tan rápido

He unido todos en un porltet para el front y otro para el backend. De está manera se han reducido a

8 hooks (Que los podría unificar todos en uno)
3 Portlets (Dospara la parte front, Otro para el back)
2 Temas
5 Layouts

Dentro de uno de los portlets del front van dentro 21 portlet

<portlet>
<portlet-name>.....</portlet-name>

<icon>/icon.png</icon>
<configuration-action-class>......</configuration-action-class>
<instanceable>false</instanceable>
<header-portlet-css>/css/main.css</header-portlet-css>
<footer-portlet-javascript>
/js/main.js
</footer-portlet-javascript>
<css-class-wrapper>....</css-class-wrapper>
</portlet>

¿Lo deberíamos plantear de otra manera?

[Juan Gonzalez，修改在10 年前。]

Hola Beatriz,

qué rapidez .

En principio tiene buena pinta. Tan sólo revisar los .jar de cada WAR, para que no haya librerias repetidas, y fijarse en los log de despliegue para ver si han sido detectados correctamente.

[Beatriz Sánchez Pérez，修改在10 年前。]

Lo tenia ya hecho por eso la rápidez, pensé que el tenerlo individuales podía afectar a las posibles caídas del servidor.

El deploy lo hace bien, no dan ningún error al hacer el despliegle.

¿Hay algo que te pueda mandar para dar alguna pista de donde puede estar el problema?

De nuevo, gracias por todo

[Juan Gonzalez，修改在10 年前。]

Hola Beatriz,

entiendo que ese cambio ya lo hicisteis sin éxito. Aun así, eso ahorrará bastante memoria.

He visto que el problema puede tener relación con la BDD, tal y como dice aquí: http://www.mchange.com/projects/c3p0/index.html#maxIdleTime, el maxIdleTime es en segundos, por lo que quizás vuestro valor es demasiado bajo. Prueba a dejar comentado jdbc.default.maxIdleTime para que coja el valor por defecto (3600) y prueba a ver.

También podríais probar a añadir a la URL del JDBC el parametro de MySQL autoReconnect=true.

[Beatriz Sánchez Pérez，修改在10 年前。]

Lo voy a probar y te digo algo.

Esto tardaré más, porque yo no llevo el entorno de producción, abriré un ticket para que lo hagan.

Gracias de nuevo por todo