Entendiendo "Java Permanent Generation"
Me he dado el permiso de traducir un texto que considero bueno, debido al sintetizado que el autor plasma para la resolución, o parte, de la problemática.
Durante mis viajes de trabajo, me he encontrado con algunos menesteres en el manejo de memoria en Java.Mi quipo ha deployado una gran cantidad de aplicaciones web en una instancia sencilla de Apache Tomcat. La caja de Linux corriendo esas aplicaciones con sólo 2GB de memoria física disponible. Una vez que las aplicaciones fueron deployadas, cerca de 1.8 Gb de la memoria es consumida por Java. Claramente, nosotros necesitamos mejorar un poco nuestro manejo de memoria.
Sin embargo, he hablado hace pocos minutos de hacer algo de "picar piedra" en la Generación Permanente de Java (Permanent Generation, en inglés) y ésta cómo se relaciona con los cúmulos de memoria de Java. Aquí algunas notas destiladas de mi investigación y que pueda serle de utilidad en las menesteres de la depuración del manejo de memoria en Java...
El argumento -Xms de Java define el tamaño máximo del cúmulo de memoria. El argumento -Xms define el tamaño inicial. Aquí un ejemplo de cómo se deben usar esos argumentos:
-Xmx1638m -Xms512m
En Tomcat, esos parámetros que se establecen deberían ir en startup.sh o en el script inicial, dependiendo de como es que tú inicias Tomcat. En lo que respecta a el MaxPermSize, este argumento ajusta el tamaño de la Generación Permanente. Cómo entiendo yo esto, la Generación Permanente mantiene información acerca de "objetos" en el cúmulo de memoria. Entonces, los cúmulos almacenan los objetos y la Generación Permanente mantiene información the "cosas" dentro de estos. Consecuentemente, cuánto mayor sea el cúmulo, mayor necesitará ser la Generación Permanente. Aquí un ejemplo de como puedes usar MaxPermSize:
-XX:MaxPermSize=128m
Aquí algunas notas adicionales sobre parámetros interesantes/importantes de la JVM:
* Usar las opciones -XX:+TraceClassLoading y -XX:+TraceClassUnloading para ver que clases son cargadas/descargadas en tiempo real. Si tu tienes dudas acerca de un exceso de clases cargadas en tu aplicación; esto podría ayudarte a encontrar que clases son exactamente las que están siendo cargadas y dónde están.
* Usar -XX:+UseParallelGC para decirle a la JVM que use multi-hilado, un hilo por CPU, para el recolector de basura. Esto podría mejorar el rendimiento del GC, ya que por defecto el GC es un sólo hilo. Define el número de hilos para que usará el GC, con la opción -XX:ParallelGCThreads={Número de Hilos aquí}
* Nunca llamar System.gc(). Esta aplicación no sabe el mejor momento pata que pase el GC, realmente sólo la JVM lo hace.
* La opción -XX:+AggressiveHeap de la JVM inspecciona los recursos de la máquina (tamaño de la memoria y el número de procesadores) e intenta establecer parámetros de memoria y del cúmulo de memoria para ser óptimos en tiempos prolongados, trabajos intensos de locación de memoria.
Sin embargo, he hablado hace pocos minutos de hacer algo de "picar piedra" en la Generación Permanente de Java (Permanent Generation, en inglés) y ésta cómo se relaciona con los cúmulos de memoria de Java. Aquí algunas notas destiladas de mi investigación y que pueda serle de utilidad en las menesteres de la depuración del manejo de memoria en Java...
El argumento -Xms de Java define el tamaño máximo del cúmulo de memoria. El argumento -Xms define el tamaño inicial. Aquí un ejemplo de cómo se deben usar esos argumentos:
-Xmx1638m -Xms512m
En Tomcat, esos parámetros que se establecen deberían ir en startup.sh o en el script inicial, dependiendo de como es que tú inicias Tomcat. En lo que respecta a el MaxPermSize, este argumento ajusta el tamaño de la Generación Permanente. Cómo entiendo yo esto, la Generación Permanente mantiene información acerca de "objetos" en el cúmulo de memoria. Entonces, los cúmulos almacenan los objetos y la Generación Permanente mantiene información the "cosas" dentro de estos. Consecuentemente, cuánto mayor sea el cúmulo, mayor necesitará ser la Generación Permanente. Aquí un ejemplo de como puedes usar MaxPermSize:
-XX:MaxPermSize=128m
Aquí algunas notas adicionales sobre parámetros interesantes/importantes de la JVM:
* Usar las opciones -XX:+TraceClassLoading y -XX:+TraceClassUnloading para ver que clases son cargadas/descargadas en tiempo real. Si tu tienes dudas acerca de un exceso de clases cargadas en tu aplicación; esto podría ayudarte a encontrar que clases son exactamente las que están siendo cargadas y dónde están.
* Usar -XX:+UseParallelGC para decirle a la JVM que use multi-hilado, un hilo por CPU, para el recolector de basura. Esto podría mejorar el rendimiento del GC, ya que por defecto el GC es un sólo hilo. Define el número de hilos para que usará el GC, con la opción -XX:ParallelGCThreads={Número de Hilos aquí}
* Nunca llamar System.gc(). Esta aplicación no sabe el mejor momento pata que pase el GC, realmente sólo la JVM lo hace.
* La opción -XX:+AggressiveHeap de la JVM inspecciona los recursos de la máquina (tamaño de la memoria y el número de procesadores) e intenta establecer parámetros de memoria y del cúmulo de memoria para ser óptimos en tiempos prolongados, trabajos intensos de locación de memoria.
Para visitar la fuente original ir aquí.
Se dice que hay que usar con mucho cuidado estos parámetros, debido a que el rendimiento de la JVM podría verse degradado en un 300%.
ResponderEliminarHay más parámetros de memoria, y claro que también diferentes usos y combinaciones posibles, dependiendo del entorno donde reside la aplicación. Daré más detalles en el libro que estoy trabajando, no es el tema principal, pero tengo que abordar el tema.
ResponderEliminar