Algo de tuning con grandes cantidades de documentos (I)

Cuando se tienen grandes cantidades de documentos a un mismo nivel de espacio de trabajo, del orden de 60000 por ejemplo, a la hora de indexar completamente o de requerir un listado, la JVM hace un uso intensivo de la memoria, sobre todo de la heap y en concreto de la llamada “Old Gen” (o “Tenured Gen”, según casos) ya que son bucles donde se crean muchos objetos que tardan en ser liberados.

Las pruebas se han realizado en una máquina virtual con 1GB de RAM con CentOS 5 (i386), JVM 1.6.0_22 y Alfresco Enterprise 3.3.4

Todos los arranques se hacen borrando previamente el directorio “lucene-indexes” y estableciendo en alfresco-global.properties la propiedad “index.recovery.mode=FULL”.

La primera prueba es arrancar con los parámetros normales que se suelen poner:

export JAVA_OPTS=”-server”
export JAVA_OPTS=”${JAVA_OPTS} -Xms128m -Xmx512m -XX:MaxPermSize=256m”

El resultado es el siguiente: (Tiempo de arranque: 630614 ms)

Se pueden observar las caídas en las gráficas cuando es lanzado el recolector de basura…

Además, al poner tantos elementos obtenemos avisos de la ehcache al sobrepasar los elementos posibles, bien, usamos la configuración que explico en el artículo http://fegor.blogspot.com/2011/01/avisos-de-alfresco-sobre-saturacion-de.html para evitar estos avisos y poder cargar más en la caché.

Además vamos a mejorar los parámetros de memoria, por un lado comprobamos que la “Perm Gen” está demasiado dimensionada con lo que la vamos a acortar para tener más posibilidades de asignarla a la heap. Además usaremos un menor tamaño de “New Gen” para adaptar mejor el tamaño a la parte “Tenured Gen”, y dejaremos el tamaño de heap como está…

export JAVA_OPTS=”-server”
export JAVA_OPTS=”${JAVA_OPTS} -Xms512m -Xmx512m -XX:NewGen=128m -XX:MaxPermSize=128m”

 El resultado mientras se arranca y reindexa, estando al rededor del 70% de reindexación completa es el siguiente: (Tiempo de arranque: 702462 ms)

Como observamos, no se aprecian grandes diferencias con respecto a la primera configuración, simplemente hemos eliminado los avisos de llenado de la ehcache pero ha tardado más en arrancar. Bien, sigamos, ahora vamos a realizar una configuración más “agresiva” usando los siguientes parámetros:

export JAVA_OPTS=”-server”
export JAVA_OPTS=”${JAVA_OPTS} -Xms640m -Xmx640m -Xss128k -XX:NewSize=320m -XX:MaxPermSize=128m”
export JAVA_OPTS=”${JAVA_OPTS} XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80″

Este es el resultado:(Tiempo de arranque: 670572 ms)

Se observa un mejor comportamiento de la memoria, si bien, la parte de “Old Gen” está algo elevada. También se ha recogido la muestra mientras indexaba sobre el 70%.

Por último vamos a retocar un poco los parámetros de la JVM y eliminar la modificación sobre el fichero hibernate-context.xml que se ha seguido en el artículo anterior.

Los parámetros establecidos quedan como:

export JAVA_OPTS=”-server”
export JAVA_OPTS=”${JAVA_OPTS} -Xms720m -Xmx720m -Xss128k -XX:NewSize=256m -XX:MaxPermSize=128m”
export JAVA_OPTS=”${JAVA_OPTS} -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80″

Y el resultado es: (Tiempo de arranque: 568476 ms)

En este último caso, la reindexación y arranque ha tardado menos tiempo si bien la memoria parece que está más aprovechada ya que se observa una mayor carga de instancias y ocupación de esta sin llegar en ningún momento a colapsarse.

Como se observa, existen múltiples configuraciones y aunque a priori parezca que no haya grandes diferencias, en muchas ocasiones puede optimizar el trabajo tanto a la hora de reindexar muchos documentos como de respuesta hacia el interface gráfico.

También se observa que Alfresco ECM cada vez se comporta mejor con grandes cantidades de documentos (obsérvese que se han creado con un tamaño pequeño y tipo texto solamente) dentro del mismo espacio de trabajo.

En la segunda parte se tocarán no solo parámetros de la JVM sino también de Alfresco ECM para acortar estos tiempos de arranque así como mejorar la gestión de la memoria.

Para obtener más información se pueden consultar los siguientes enlaces:

http://wiki.alfresco.com/wiki/JVM_Tuning#Maximum_JVM_Heap_Size_32.2F64bit
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
http://fegor.blogspot.com/2011/01/avisos-de-alfresco-sobre-saturacion-de.html

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *