miércoles, 16 de julio de 2014

Afinamiento de la JVM para JBoss

En las versiones mas recientes de la Sun Java Virtual Machine – JVM denominada también “HotSpot”, se ha implementado mejoras en dos aspectos importantes como son el proceso de garbage collector y en la parametrizacion de los pools de memoria que usan las aplicaciones denominado HEAP.

La configuración por defecto de la JVM normalmente es adecuada para iniciar un periodo de observación del comportamiento de las aplicaciones, si la elección de los parámetros por defecto no satisface los requerimientos entonces es posible realizar ciertas tareas de afinamiento de la JVM para mejorar el  desempeño de las aplicaciones.

Generaciones

El Heap, la memoria utilizada por la JVM para almacenar los datos se distribuye en los siguientes pools:



Se divide el Heap partiendo de la hipótesis de que gran parte de los objetos reside un corto tiempo en el heap. El Eden es el área donde se crean los nuevos objetos, el área de Survivor es el área donde se reciclan los objetos intermedios, el área Virtual es una área de reserva para el crecimiento del pool, en total existen dos áreas de Survivor y siempre uno debe estar disponible. El Tenured es un pool donde se almacenan los objetos mas antiguos, y el área permanente (Perm) es donde residen los objetos que estarán siempre o permanentemente en la memoria como son los datos necesarios para la operación de la JVM y aquellos que describen clases y métodos. La generación young, esta conformada por el Eden y los dos espacios de survivor

Garbage Collection

Muchos de los objetos “mueren jóvenes”, es decir en el la generación young, esto se representa en la figura 2, cuando el young esta lleno se produce un garbage Collection llamado minor Collection, que elimina de la memoria todos los objetos de la generacion young que ya no son alcanzables por ningun puntero de alguna aplicación que se este
ejecutando. En un ciclo tipico de minor Collection una fraccion de los objetos que residen en el young son movidos al tenured. Cuando el tenured se llena ocurre un major collection que resulta en una recoleccion de objetos inalcanzables de todo el head, un minor Collection normalmente es mucho mas rapido que un major Collection que hace
un barrido de todo el pool de heap.



Medidas de Desempeño del Garbage Collection

Las siguiente son medidas de desempeño a tener en cuanta:

Throughput: es el porcentaje del total de tiempo que no se hace garbage collection sobre periodos largos de tiempo. El throughput incluye el tiempo gastado en hacer asignaciones.

Pausas: son las veces que la aplicación parece no responder porque el garbage collection esta ocurriendo.

Footprint: es el trabajo conjunto de un proceso, medido en caché de páginas y líneas

Promptness: es el tiempo transcurrido entre que el objeto será desalojado (muere) y cuando se disponga de la memoria

Las medidas más importantes son las dos primeras y sirven para priorizar objetivos.

Garbage Collector Disponibles

Serial Collector

Usa un solo thread para el proceso de garbage collection, es ideal para maquinas con un solo cpu. Para maquinas con mas de un cpu es conveniente cuando se mantiene un conjunto pequeño de datos aproximadamente menor a 100 MB.

Se selecciona por defecto en ciertas plataformas pero se puede habilitar con
–XX:+UserSerialGC.

Parallel Colector

Ejecuta los minor collection en paralelo, para los major collection usa un solo thread presenta un mejor desempeño en maquinas con varios cpu, es ideal para aplicaciones que mantienen medianos o grandes conjuntos de datos. En sistemas operativos multithread con jdk 5.0 se selecciona por defecto sin embargo se puede seleccionar explícitamente con: –XX:+UseParallelGC

En J2SDK 5.0 fue introducida la característica de parallel compaction, esta permite ejecutar los procesos major collection en paralelo. Se habilita con la opcion:
-XX:+UseParallelOldGC

En maquinas con N cpus, el parallel collector usa N threads, el numero de garbage collector threads puede controlarse con: -XX:ParallelGCThreads=<N>

En maquinas con un solo cpu, el serial collector podría ser mejor por el overhead que cusa la sincronización de los threads en paralelo, cuando se usa el parallel collector con un solo cpu.

Concurrent Collector

Ejecuta el trabajo del garbage collection concurrentemente con la aplicación para tener pausas cortas de garbage collection. Se usa en aplicaciones que mantienen medianos o grandes conjuntos de datos. Es conveniente cuando el tiempo de respuesta es mas importante que el throughput en general (esta técnica puede reducir el desempeño de la aplicación). Se habilita con –XX:+UseConcMarkSweepGC
Compartir:

0 comentarios:

Publicar un comentario