Algo de tuning con grandes cantidades de documentos (II)

Este es el segundo artículo sobre tuning cuando se encuentran muchos documentos dentro del mismo nivel o espacio de trabajo y es continuación del artículo anterior: http://fegor.blogspot.com/2011/03/algo-de-tuning-con-grandes-cantidades.html

Seguimos con la configuración de un sistema con 60 mil documentos (muy pequeños) en el el mismo nivel de espacio de trabajo. Se me olvidó decir que las pruebas se han realizado sobre una máquina virtual en Virtual Box.

Partimos de la última cadena de configuración que usamos en el artículo anterior añadiendo también los parámetros para poder conectar vía JMX con la utilidad jconsole que es la usada para monitorizar los arranques:

export IP_ADDR=»`hostname -i`»
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″
export JAVA_OPTS=»${JAVA_OPTS} -Dalfresco.home=${ALF_HOME} -Dcom.sun.management.jmxremote»
export JAVA_OPTS=»${JAVA_OPTS} -Djava.rmi.server.hostname=${IP_ADDR}»

Seguidamente se «optimiza» más la propia configuración de Alfresco ECM añadiendo al fichero alfresco-global.properties lo siguiente:

# Desconectar auditorías
audit.enabled=false
audit.useNewConfig=false

# Conexiones máximas a la BD
db.pool.max=275

# Reducción de conexión (8 por defecto)
db.pool.idle=-1

# Tamaño de filas para consultas (10 por defecto)
hibernate.jdbc.fetch_size=150

# Límite de tiempo mínimo para indexar en background
lucene.maxAtomicTransformationTime=0

# Tiempo para el tracking
index.tracking.cronExpression=0/5 * * * * ?

Cortesía de las Alfresco Master Classes y Toni  de la Fuente.

Los resultados han sido los siguientes: (Tiempo de arranque: 565879 ms)

Ahora cambiamos en contentModel.xml en el tipo cm:content la propiedad «atomic» a «false», y remodificamos los parámetros de la JVM y volvermos a probar por última vez…

export JAVA_OPTS=»-server»
export JAVA_OPTS=»${JAVA_OPTS} -Xms720m -Xmx720m -Xss128k -XX:NewSize=128m -XX:MaxPermSize=128m»
export JAVA_OPTS=»${JAVA_OPTS} -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=50″
export JAVA_OPTS=»${JAVA_OPTS} -XX:MaxGCPauseMillis=1500 -XX:GCTimeRatio=9″
export JAVA_OPTS=»${JAVA_OPTS} -Dalfresco.home=${ALF_HOME} -Dcom.sun.management.jmxremote»
export JAVA_OPTS=»${JAVA_OPTS} -Djava.rmi.server.hostname=${IP_ADDR}»

El resultado final es: (Tiempo de arranque: 520523 ms)

Bien, Pero ¿que pasa si queremos introducir 150 mil documentos o más por nivel? Para esto antes modificaremos los valores de ehcache-context.xml para que puedan almacenar valores muy elevados así como en el fichero ehcache-transactional.xml subiremos el número de elementos en memoria  (maxElementsInMemory=»150000″) y el parámetro de JVM «-XX:NewSize» lo ajustaremos según las necesidades.

Por ejemplo:

Fichero: ehcache-transactional.xml

[…]

     
        
     
     
        
     
     
         org.alfresco.cache.contentDataTransactionalCache
     
     
         150000
     
  
[…]

     
        
     
     
        
     
     
         org.alfresco.storeAndNodeIdTransactionalCache
     
     
         150000
     
  
[…]

Un script para crear documentos de prueba podría ser:

Fichero: crear_documentos.js
var doc;
for(var i=1; i<150000; i++)
{
    doc = companyhome.createFile(«doc-» + i + «.txt»);
    doc.content = «Texto-» + i + «. Esto es una prueba de creación de documento para comprobar la capacidad de indexación, recuperación, etc. ABCDEFGHYJKLMNÑOPQRSTUVWXYZ0123456789 ABCDEFGHYJKLMNÑOPQRSTUVWXYZ0123456789 «;
    doc.save();
}

El principal problema que nos encontramos aquí es que al crearse objetos dentro de un bucle, estos no son liberados tan rápidamente y pasan a la parte de «CMS Old Gen» de la heap que es la que recibe más carga por lo que habrá que ajustar tanto los tiempos de pasadas del GC como el tamaño de la memoria «a corto plazo» o «New Gen», esto puede establecerse con el parámetro -XX:NewSize.

También hay que tener en cuenta la configuración y optimización de MySQL.

Finalmente, una cadena de arranque para la JVM que es bastante útil en el caso de cargas masivas para plataformas 32 bit (para 64 bit se puede incrementar la heap al doble o al triple) sería:

export IP_ADDR=»`hostname -i`»
export JAVA_OPTS=»-server»
export JAVA_OPTS=»${JAVA_OPTS} -Xms1384m -Xmx1384m -Xss128k -XX:MaxPermSize=128m -XX:NewRatio=2″
export JAVA_OPTS=»${JAVA_OPTS} -XX:+OptimizeStringConcat -XX:+UseLargePages -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:-UseParallelGC»
export JAVA_OPTS=»${JAVA_OPTS} -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80″
export JAVA_OPTS=»${JAVA_OPTS} -XX:GCTimeRatio=9″
export JAVA_OPTS=»${JAVA_OPTS} -Dalfresco.home=${ALF_HOME} -Dcom.sun.management.jmxremote»
export JAVA_OPTS=»${JAVA_OPTS} -Djava.rmi.server.hostname=${IP_ADDR}»
export JAVA_OPTS=»${JAVA_OPTS} -Djava.io.tmpdir=${ALF_HOME}/tomcat/temp»

La memoria asignada a la máquina virtual (Virtual Box) es de 1GB. y la de la JVM es más de 1GB. (1385 MB.) por lo que esta hará «swaping» a disco.

En resumen, el tema de optimización de la JVM y Alfresco ECM con cargas masivas de documentos o creación de estos y más en el mismo nivel no es trivial pero siempre se puede «forzar» para que al menos realice el trabajo inicial y posteriormente ir descargando los espacios de trabajo en estructuras de más profundidad para disminuir la carga en memoria de tantas referencias.

Deja una respuesta

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