nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

1 millón de archivos en share

normando

Hola a todos

Estoy un poco temeroso. Resulta que una compañía desea que le incluyamos 1.000.000 de archivos tif (50kb cada uno) en nuestro servidor (i5 - 4gb DDR3 - 1Tb sata2 - Centos 5.5 32bits). Dada la sugerencia de Pedro, estoy pensando en Share.

Es posible? Estoy seguro que sí, pero la cifra me asusta. El servidor obviamente es un exclusivo para utilizar alfresco.

Gracias

Find more posts tagged with

Comments

mikel_asla1

Buenas!
Eso son 47 Gigas. ¿Tienes ese espacio libre?
A parte sumale los metadatos de cada archivo (almacenados en BBDD), más los indices de lucene (almacenados en repositorio), suponiendo que el gestor de bases de datos que uses este en la misma maquina, no creo que supere los 50Gigas.
Otro asunto, puedes establecer cuotas de disco, o simplemente monitorizar el espacio libre y redimensionar en caso necesario.
¿Quién dijo miedo?

pjcaracuel_2349

Hola Normando,

El otro dia estuve con gente de ALfresco y me comentaron que tenían instalaciones con mas de 200 millones de documentos. Yo he trabajado con aplicaciones de alfresco que gestionaban 4 millones de documentos.

Como dice Mikel, todo es espacio en disco, si lo dimensionas bien, sin problemas.

Saludos

fegor

Hola,

Claro que puedes tener un millón de documentos (que no nodos ;-)) pero una par de cosillas:

1. Si son ficheros TIFF todos y no necesitas la inexación de contenido, mejor desconéctala y así irá mejor, de todas formas no vas a buscar por el contenido ¿no?… 😉

Para esto, en el fichero contentModel.xml pon a "false" la indexación "<index enabled=xxxxx>":

<type name="cm:content">
         <title>Content</title>
         <parent>cm:cmobject</parent>
         <archive>true</archive>
         <properties>
            <property name="cm:content">
               <type>d:content</type>
               <mandatory>false</mandatory>
               <!– Although content is marked as indexed atomically it may end up asynchronous –>
               <!– if the content conversion will take too long. Content that does not require conversion –>
               <!– to UTF8 test/plain will always be indexed atomically –>
               <index enabled="false">
                  <atomic>true</atomic>
                  <stored>false</stored>
                  <tokenised>true</tokenised>
               </index>
            </property>
         </properties>
      </type>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

2. Un sistema de 32 bits no te lo recomiendo con esas cantidades de nodos, mejor intenta que se cambie la arquitectura por un sistema de 64 bits., siempre tendrás más posibilidades de tener más memoria "heap" para trabajar.

Un saludo.

normando

Muchas gracias a todos por sus respuestas. Todas han aportado mucho. Me quedo más tranquilo entonces.

Espacio en disco tengo bastante, ya que es un HD de 1TB. Memoria no es mucha, pero son 4GB.

Con respecto a lo que menciona Fernando, estoy un poco complicado de migrar ahora todo a 64bits. Esto es algo indispensable dada la cantidad de nodos, o es algo que sólo mejoraría el funcionamiento de Alfresco? Lo pregunto, porque si es seguro que no va a funcionar con esa cantidad de nodos en 32bit, lo migraría a 64. Según tengo entendido, en 32bits a nivel de filesystem es posible anidar 32000 archivos en un mismo directorio, lo que está muy lejos de satisfacer mi necesidad. Lo que creo es que Alfresco no utiliza el filesystem de la manera habitual para guardar los nodos, es decir, si creo una carpeta en share docs y guardo allí 1.000.000 de archivos, Alfresco crear un directorio en el filesystem y mete allí el millón de nodos? Si es así, estoy liquidado.

Con respecto al índice, muy buena la sugerencia. En este caso necesito que sea indexable por medio del script OCR con tesseract que publiqué en el otro foro.

Saludos

fegor

A ver, el tema de los 64 bits es solo por redireccionamiento, en 32 bits solo podrás poner un máximo de 1,5GB. de memoria heap en la JVM de Sun. Solo es eso, si te apañas con eso no tendrás problemas, pero por si a caso, más vale tener más arquitectura que quedarte corto a mitad… ¿no?

Por el otro tema, el del filesystem no te preocupes, a no ser de que en un solo minuto subas más de 32767 ficheros en un filesystema de tipo ext3 por ejemplo… jejeje, Alfresco usa un sistema por directorios usando año/mes/dia/hora/minuto para no tener problemas con la cantidad de nodos posibles en un mismo directorio.

Un saludo.

normando

Gracias Fer por la explicación.

Yo en JAVA_OPTS coloqué lo siguiente:

export JAVA_OPTS="-server -Xss1024K -XX:NewSize=512m -XX:MaxPermSize=512m -Xms1g -Xmx2g -Dalfresco.home=/opt/alfresco -Dcom.sun.management.jmxremote"

No sé si es correcto. espero no quedarme corto muy pronto con los 32 bits

fegor

Hola, a ver, primero, pon parámetros de la JVM que controles perfectamente y sepas lo que hacen, si no, seguramente sea peor. Los "chicos" de Sun ya se han encargado de ajustar bastante los parámetros por defecto para casos de uso de lo más variado. A veces hacer que el GC salte mucho es muy malo, igual que alargar demasiado este proceso,…

A ver, siguiendo la línea de opciones que has puesto:

export JAVA_OPTS="-server -Xss1024K -XX:NewSize=512m -XX:MaxPermSize=512m -Xms1g -Xmx2g -Dalfresco.home=/opt/alfresco -Dcom.sun.management.jmxremote"‍

Me parece bien, unas consideraciones:

Si no usas mucha recursividad, muchos "ReindexFull" no tienes por qué subir tanto la memoria de pila, el sistema lo tiene en 64k, lo puedes poner en 128k o en 256k y si ves que luego (mediante monitorización) necesitas más pues le das más.

No soy muy amigo de tocar parámetros como la "NewSize" pero bueno, está dentro de los límites.

Usa siempre valor mínimo y máximo, y en producción iguálalos para que no tenga que reubicar tanto, p.e. si pones -XX:MaxPermSize=512m, pon también el parámetro -XX

ermSize=512m. (es una opinión personal, que conste)

Igualmente para la Heap, usa el mismo valor, -Xms2g y -Xmx2g (yo prefiero ponerlo en MB, p.e. -Xms2048m y -Xmx2048m, pero como te digo, esto ya es más una manía mía)

Y sobre todo, una vez arrancado, usa JConsole para monitorizar la memoria, como sube, si hace bien una gráfica tipo "sierra", si la parte de Non Heap (sobre todo Perm) se mantiene y puedes ajustarla mejor, etc.

Más cosas:

Afina bien la parte de MySQL para que no te haga mucho cuello de botella, intentan usar 64 bits aunque veo que no tienes muchas posibilidades, usa unidades de almacenamiento rápidas (p.e. discos de 10000rpm, etc.), un filesystem que sea robusto como ext4, zfs, etc. o bien GFS, OCFS2, VxFS,… si vas a montar finalmente en clúster.

El tema de clúster es importante si vas a tener mucha carga, ojo, que no muchos documentos, me refiero al tema de muchas peticiones al servidor. Para esto evidentemente deberías usar JGroups y la versión Enterprise de Alfresco.

Un saludo.

normando

Mucha gracias Fernando

Para mi el tema Java y todos sus servidores derivados (tomcat, jboss, etc) son un verdadero problema, porque no me siento muy a gusto. Mira que programo en C++ sin inconvenientes, y la similitud con Java es enorme, pero… no sé, es una cuestión de piel. Quizás deba tomar algún curso breve que me saque de la ignorancia en cuanto a Java, y quizás podré comprender mejor las cosas. Por el momento, tomo recetas, y claro, no soy tan neófito, muchas cosas las comprendo.

En particular éste asunto de los ajustes del tomcat, no tengo la más mínima idea teórica. Sólo se que dispongo de 4G de RAM para emplear exclusivamente en alfresco (+ mysqld). Mysql lo tengo bien afinadito, en ello sí tengo experiencia y conocimiento.

Nuevamente gracias por tus valiosas explicaciones.