• Lentitud al 'asimilar' un repositorio grande

  • Hemos intentado hacer de OpenKM una aplicación lo más intuitiva posible, sin embargo siempre viene bien algún consejo.
Hemos intentado hacer de OpenKM una aplicación lo más intuitiva posible, sin embargo siempre viene bien algún consejo.
Forum rules: Por favor, antes de preguntar algo consulta el wiki de documentación o utiliza la función de búsqueda del foro. Recuerda que no tenemos una bola de cristal ni poderes mentales, o sea que que para informar sobre un error es necesario que nos indiques tanto la versión de OpenKM que usas como la del navegador y sistema operativo. Para más información consulta Cómo informar de fallos de forma efectiva.
 #2964  by jlvazquez
 
Estoy intentando levantar una replica de nuestro OpenKM (3.0 Community Edition) en producción porque debemos sustituir el servidor físico por otro con más capacidad.

Por el camino me he encontrado los siguientes escollos una vez levantada la nueva instancia vacia de OpenKM en la nueva maquina:

1) Si la instancia a la que quiero migrar los datos usa almacenamiento en ficheros (y no en mysql) para los documentos, cuando hago la importación tarda varias horas en completarla.

2) Si la instancia destino usa mysql para todo, incluidos los documentos (que mete como blobs), cuando importo la BD original tarda unos minutos, pero luego, al arrancar la aplicación con un directorio repository vacio, esta se queda frita literalmente durante horas también con Java ocupando el 100% de la CPU. Parece como si estuviese improtando o inexando en ese momento los datos ¿Pero esto no se hace en la propia BD? ¿Tiene que re-indexar los ficheros en repository? ¿para que?

¿Que estoy haciendo mal?
¿Debo copiar el estado de repository/ de la maquina original aunque el almacenamiento de los datos sea en blobs de la db?

El tamaño del repositorio actual es de 2,5GB.
 #2975  by jllort
 
El proceso de migración es normalmente lento y puede tardar en segun que casos un par de horas ( eso es normal ). En los cambios de version de openkm hay cambios de estructura por lo que el proceso de migración lo que hace es \"volver a subir los ficheros\" pero conservando fechas etc... esto implica que hay que volver a reindexar los documentos, cosa que no se hace a nivel de base de datos sino a nivel del motor de indexación ( lucene ).
 #2992  by mlobo
 
Buenas,

tengo una consulta respecto a dos aspectos:

1. Como trabaja la BD, esta maneja los archivos? lo pregunto por que de ser asi, cuando se maneje un repositorio relativamente grande como de unos 5Gb es probable que la aplicacion se ponga muy lenta lo que haria poco agil su uso.

2. Al migrar la aplicacion de un equipo a otro que implicaciones hay? es necesario volver a cargar todo de la informacion, taxonomia y demas? o simplemete se restaura la aplicacion a partir de un backup del repositorio?
 #3008  by jllort
 
Esto ya te lo he contestado ya en el otro threat.

About Us

OpenKM is part of the management software. A management software is a program that facilitates the accomplishment of administrative tasks. OpenKM is a document management system that allows you to manage business content and workflow in a more efficient way. Document managers guarantee data protection by establishing information security for business content.