• TAMAÑO DEL REPOSITORIO ENORME Y NO CONCUERDA CON LA INFORMACIÓN ALMACENADA

  • 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.
 #46430  by ceginfor
 
Buenas tardes, llevamos una semanas notando que el tamaño del repositorio está aumentando considerablemente y no se corresponde con el tamaño de la información almacenada.

Actualmente el tamaño físico de la carpeta /repository/datashore es de 107 GB y ayer era de 103 GB. Estamos seguros que no se ha subido esa cantidad de información al gestor.

Nuestro disco duro es de 150 GB y solo nos queda disponible 16 GB, lo cual concuerda con las estadísticas que nos facilita el gestor documental y que les adjunto. Pero como también se puede comprobar el tamaño de los documentos por contenido no llega a los 28 GB.

Como dato, indicarle que yso base de datos mysql y el tamaño de la carpeta /var/lib/mysql es de 4,9 GB

¿Qué puede estar ocurriendo?

Un saludo.
Attachments
Estadísticas Uso Disco.jpg
Estadísticas Uso Disco.jpg (65.53 KiB) Viewed 6298 times
 #46433  by lnovoa
 
Hola,
¿tienes algún crontab que pueda ejecutar un script por ejemplo donde se estén duplicando ficheros o algo por el estilo?
Parece que si el repositorio está incrementando de esta forma es por algún tema de estos.
¿Cuál es el tamaño de aumento por día¿, ¿siempre es el mismo o varía?
 #46438  by ceginfor
 
Buenos días, en primer lugar muchas gracias por su interés.

En principio solo existe un tarea en el crontab para realizar la copia de seguridad y que se ejecuta una vez a la semana, los sábados concretamente, la cual es parado también para descartar que el problema venga de aquí y por falta ya de espacio en disco.

En ella hago copia de seguridad de la base datos (una con tar del directorio mysql de 760 MB y otra con mysqldump de 2,6 GB) y toda la carpeta repository con un tar.

La cuestión es que el aumento de tamaño se produce también los días entre semana por lo que he descartado esa posibilidad. El resultado de la copia se guarda naturalmente fuera del repositorio, y es este el que ve incrementado su tamaño por lo que he podido comprobar.

Fecha Usado disco Libre Repository
23/07/2018 104 GB 38 GB
26/07/2018 112 GB 29 GB
30/07/2018 124 GB 18 GB 103 GB
31/07/2018 128 GB 13 GB 107 GB


Un saludo.
 #46439  by ceginfor
 
Actualizo el informe de espacio en disco:

Fecha Usado disco Libre Repository
23/07/2018 104 GB 38 GB
26/07/2018 112 GB 29 GB
30/07/2018 124 GB 18 GB 103 GB
31/07/2018 128 GB 13 GB 107 GB
01/08/2018 128 GB 14 GB 111 GB

Eliminé los ficheros de las copias de seguridad de la base de datos para obtener más espacio, de ahí las diferencias entre usado y libre de ayer y hoy. Pero sí hay un dato a destacar, el aumento de unos 4 GB diarios del repositorio, que estoy seguro que no se corresponde con información subida manualmente.
 #46450  by jllort
 
Lo que identificas como el tamaño del repositorio puede perfectamente ser los logs. Para la apliación y borra todos los ficheros de la carpeta de logs.

Te sugiero instalar alguna utilidad como ncdu para identificar en que carpeta realmente está localizado este consumo elevado de disco. Por aquí tienes información adicional sobre comandos del sistema operativo en este sentido https://unix.stackexchange.com/question ... mmand-line
 #46466  by jllort
 
Mira en el activity log los documentos creados o actualizados https://docs.openkm.com/kcenter/view/ok ... y-log.html

En base de datos la tabla se llama OKM_ACTIVITY y los eventos que te interesan son:
CREATE_DOCUMENT
COPY_* ( igual tienes un copy - recursivo - o alguna historia estraña ? )
CHECKIN_DOCUMENT

A ver que te sale
 #46498  by ceginfor
 
Buenos días y muchísimas gracias por su respuesta. Siento no haber podido contestar antes pero hemos estado todo este tiempo investigando y analizando el problema, que ya creemos resuelto. Gracias a su aportación, hemos consultado dicha tabla y creemos que está relacionado con el tipo de configuración de la cuenta o por lo menos con los correos de dicho usuario (adjunto imagen), ya que como se puede comprobar se creaban en el sistema continuamente emails, desde el 5 de julio hasta el día 2 de agosto.

La duda que tenemos aún es el por qué de se comportamiento. ¿Puede ser debido, tal cómo pensamos a un cambio del tipo de cuenta de correo?

Se corresponde con un usuario a cual su administrador le cambió el tipo de cuenta de correo de IMAP a POP3. Buscando la solución del problema, nos dimos cuenta y detectamos este cambio, y pensando que podría ser el motivo, volvimos a poner el tipo de cuenta a IMAP. Entendemos que si la cuenta es de tipo POP, se descargan los correos al gestor documental y si es IMAP, está sincronizados con el servidor y no se descargan ¿verdad?

En principio el problema persistió (o por lo menos parecía, creemos que tardó un poco en parar) y ya fue cuando eliminamos los logs. El viernes día 3 cesó el problema, pero hemos estado todo este tiempo observándolo por si volvía a repetirse y además intentado descubrir cuál era el verdadero motivo, porque el tema de los logs no nos terminaba de cuadrar, ya que se guardan en una carpeta por encima del repositorio.

Por tanto, ¿cree usted que podría ser el motivo?. Teniendo en cuenta que es imposible que el usuario tenga 100 GB en su cuenta de correo ¿Se han descargado los mismos correos de ese usuario todos los días? ¿Cómo se podría recuperar el espacio "perdido"?

Un saludo y muchísimas gracias.
Attachments
Registro Actividad Logs.jpg
Registro Actividad Logs.jpg (468.57 KiB) Viewed 6203 times
 #46514  by jllort
 
No exactamente, el IMAP tiene un contador interno que lo que hace es indicar por donde vas en el proceso de lectura, cosa que no pasa en el POP. El problema es que el POP sólo debería consumirse por un único lector y lo teneis configurado para que lea correos y no elimina nada, por lo que continuamente esta leyendo los mismos correos hasta el infinito.

En definitiva -> cuenta POP -> 1 solo consumidor y en general borrar los correos del servidor
Cuenta IMAP varios consumidores ( un detalle, al editar la cuenta el contador de IMAP se resetea, es como una configuración de cero, con esto teneis que ir con cuidado en las configuraciones de IMAP )
 #46526  by ceginfor
 
Buenos días Jllort, de acuerdo, entiendo. Pero me surgen unas dudas más:

¿Para que una cuenta de tipo POP se eliminaran los correos habría que activar la casilla Mail mark deleted verdad?

Cuando se refiere a "proceso de lectura" de los correos, ¿en ambos casos el gestor documental descarga o solo está sincronizado con el servidor de correos, es decir si se elimina el correo del servidor desaparece del gestor documental?

¿Cómo podríamos eliminar ese espacio en disco de los correos que se han descargado en bucle? ¿Se podría eliminar la cuenta del usuario y volverla a crear en el gestor?

Un saludo y muchísimas gracias de nuevo.
 #46535  by jllort
 
La idea de una cuenta pop es leer el correo y en general borrarlo del servidor. En este caso OpenKM lo leería y con el mark to delete, lo eliminaria después de importarlo ( no tendrías el problema de la cola infinita que siempre va leyendo lo mismo ).

Como supongo que no has borrado nunca ningún correo de la cuenta pop que tienes configurada. Igual lo mas sencillo :
1- Desactivar la cuenta pop
2- es eliminar todos los correos que cuelgan de ese usuario en la carpeta /okm:mail/userId ( tardará un buen rato por lo que dices ) y después vaciar la papelera
3- Activar la cuenta pop y marcar los correos para ser eliminados
 #46597  by jllort
 
Si tiene IMAP el problema no debería presentarse porque en IMAP se guarda el último correo leído. En este escenario lo único que tiene que tenerse en consideración es que si editas la cuenta de mail, nosotros no podemos saber de que tipo de cambio se trata por lo que siempre se resetea el contador ( en el caso de una edición se tiene que ir con cuidado en este sentido y en caso que no se quiera que se resetee, guardar previamente el valor que esta en la base de datos -> tabla OKM_MAIL_ACCOUNT para posteriormente restaurarlo ). Efectivamente, no es muy cómodo, pero no hemos encontrado una lógica que pueda servir para todos los casos ( como mucho igual podríamos solicitar en el edit si se desea resetear el valor o no )

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.