java - and - intellij idea configure wildfly
La aplicación Grails acapara mucha memoria (3)
Tomcat 5.5.x y 6.0.x
Grails 1.6.x
Java 1.6.x
OS CentOS 5.x (64 bits)
Servidor VPS con memoria como 384M
JAVA_OPTS: intenté muchas combinaciones, incluidas las siguientes
exportar JAVA_OPTS = ''- Xms128M -Xmx512M -XX: MaxPermSize = 1024m''
exportar JAVA_OPTS = ''- servidor -Xms128M -Xmx128M -XX: MaxPermSize = 256M''
(Según lo recomendado por http://www.grails.org/Deployment )
He creado una aplicación Grails en blanco, es decir, simplemente dando el comando grails create-app y luego WARed it
Estoy ejecutando Tomcat en un servidor VPS
Cuando simplemente inicio el servidor Tomcat, sin aplicaciones desplegadas, la memoria libre es de aproximadamente 236M y la memoria utilizada es de aproximadamente 156M
Cuando despliego mi aplicación "en blanco", el consumo de memoria aumenta a 360M y finalmente la instancia de Tomcat se cancela tan pronto como ocupa toda la memoria libre
Como has visto, mi aplicación es tan liviana como puede ser.
No estoy seguro de por qué el consumo de memoria es tan alto.
De hecho, estoy solucionando problemas en una aplicación real, pero me he limitado a este escenario, que es más fácil de compartir y explicar.
ACTUALIZACIÓN Probé la misma aplicación "en blanco" en mi Tomcat 5.5.x local en Windows y funcionó bien
El consumo de memoria del proceso de Java se disparó de 32 M a 107M. Pero no se bloqueó y se mantuvo por debajo de los límites aceptables
Así que la búsqueda de respuestas continúa ... Me pregunto si algo está mal con mi caja de Linux. No estoy seguro de qué ...
ACTUALIZACIÓN 2 También vea este http://www.grails.org/Grails+Test+On+Virtual+Server
Confirma mi creencia de que mi aplicación en blanco debería funcionar en mi configuración.
¿Puedes intentar implementar una aplicación web de supervisión de tomcat, por ejemplo, psiprobe, y ver dónde se está utilizando la memoria?
384MB es bastante pequeño. Estoy ejecutando una pequeña aplicación de Grails en un VPS de 512 MB en enjoyvps.net (no afiliado de ninguna manera, solo un cliente feliz) y ha estado funcionando durante meses con poco menos de 200 MB. Sin embargo, estoy ejecutando un Linux y un JDK de 32 bits, no tiene sentido desperdiciar toda esa memoria en punteros de 64 bits si no tiene acceso a mucha memoria de todos modos.
Es una falsa economía intentar ejecutar una aplicación basada en Java de larga ejecución en la memoria mínima posible. El recolector de basura, y por lo tanto la aplicación se ejecutará de manera mucho más eficiente si tiene un montón de memoria de montón regular. Deje una aplicación con un montón demasiado pequeño y pasará demasiado tiempo recogiendo basura.
(Esto puede parecer un poco contra-intuitivo, pero créanme: el efecto es predecible en teoría y observable en la práctica).
EDITAR
En términos prácticos, sugeriría el siguiente enfoque:
Comience ejecutando Tomcat + Grails con la mayor cantidad de memoria posible para que tenga algo en ejecución. (Establezca el tamaño de permgen en el valor predeterminado ... a menos que tenga pruebas claras de que Tomcat + Grails están agotando el permgen).
Ejecute la aplicación por un tiempo para obtener un estado estable y descubrir cuál es su conjunto de trabajo promedio. Debería poder averiguarlo desde un generador de perfiles de memoria, o examinando el registro de GC.
Luego configure el tamaño del almacenamiento dinámico de Java para que sea (digamos) dos veces el tamaño del conjunto de trabajo medido o más. (Este es el punto que estaba tratando de hacer arriba).
En realidad, hay otra causa posible para sus problemas. Aunque le está diciendo a Java que use montones de un tamaño determinado, es posible que no pueda hacerlo. Cuando la JVM solicita memoria del sistema operativo, hay un par de situaciones en las que el sistema operativo se rechazará.
Si la máquina (real o virtual) con la que está ejecutando el sistema operativo no tiene más memoria "real" sin asignar y el espacio de intercambio del sistema operativo está completamente asignado, deberá rechazar solicitudes de más memoria.
También es posible (aunque poco probable) que los límites de memoria por proceso estén en vigor. Eso haría que el sistema operativo rechace solicitudes más allá de ese límite.
Finalmente, tenga en cuenta que Java usa más memoria virtual que puede ser contabilizada simplemente al sumar los números de pila, pila y permgen. Existe la memoria utilizada por el ejecutable + DLL, la memoria utilizada para los búferes de E / S y posiblemente otras cosas.