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.

Espace de Stockage

maurice

Config : Alfresco Community 2.1 - Linux
—

Bonjour,

Nous sommes en train de migrer le fond documentaire de près de 50GO sur notre serveur IBM x3550 de 300GO (pour Alfresco), plusieurs questions :

1- Si on souhaite copier notre base documentaire, via un disque externe, où devons nous copier les donner sur le serveur ?
2- Lorsqu'on clique droit sur le serveur (sous windows en mode en CIFS), il apparait 78,10GO et non 300GO, est-ce normal ?
3- Comment garder simplement la "creation date" des documents lors du transfert ?
4- Comment changer l'adresse émettrice par défaut des alertes mails (Cf. règles) venant du serveur ?
5- Comment changer le lien sur les raccourci Alfresco créé automatiquement à la racine de chaque espace ?

Merci de votre aide,

Find more posts tagged with

Comments

michaelh

Si on souhaite copier notre base documentaire, via un disque externe, où devons nous copier les donner sur le serveur ?

On ne doit rien copier directement sur le serveur, on doit utiliser une interface type CIFS ou FTP par exemple.

Lorsqu'on clique droit sur le serveur (sous windows en mode en CIFS), il apparait 78,10GO et non 300GO, est-ce normal ?

Oui, c'est la JVM qui a du mal à faire le calcul et sort cette valeur. Ca ne change rien à l'espace réellement disponible.

Comment garder simplement la "creation date" des documents lors du transfert ?

La date de création n'est pas stockée dans le document à proprement dit, mais sur le système de fichier d'origine. Des solutions existent, mais qui impliquent de mettre fortement les mains dans le moteur je dirais

Comment changer l'adresse émettrice par défaut des alertes mails (Cf. règles) venant du serveur ?

De mémoire (je suis fainéant ce matin moi !), dans le fichier repository.properties

Comment changer le lien sur les raccourci Alfresco créé automatiquement à la racine de chaque espace ?

J'imagine qu'on parle de CIFS. Si oui, c'est dans le fichier file-servers-custom.xml

maurice

Merci de tes réponses rapide.

Les données qu'on souhaite transférer sont près de 50 Go :
33,1GO soit 51170 fichiers dans 2400 dossiers
18,6GO soit 22000 fichiers dans 2700 dossiers

Le type de données sont :
- Documents (Word, PDFs …)
- Packages Installation Oracle, Code Sources …

Le transfert est très très lent (+ de 10h). Nous pensons que c'est parce que Alfresco utilise JAVA pour le retraitement des fichiers transférés ce qui est long.

Mais le type de données peut aussi jouer ?

Si oui, que devrait-on faire ? Ne transférer que les documents ? Booster le JAVA ? Si oui, comment ?

Merci de ton aide,

michaelh

Je ne pense pas que ce soit lent "à cause de Java" (c'est une vieille idée qui perdure et qui n'est plus d'actualité).

Il faut savoir que lors de l'insertion, Alfresco fait l'indexation à la volée, et si il y a des fichiers sources sous forme texte et pas mal de documents, ça fait vite beaucoup de travail. Le temps que tu annonces n'est pas délirant …

Une solution pourrait être de désactiver l'indexation le temps de l'import, mais il faudra bien la faire à un moment ou à un autre de toute façon (et puis si on peut éviter de trop faire de modification ce n'est pas plus mal).

Quelques questions :
- Est-ce que le CPU est utilisé à 100 % ? Ce n'est pas certain
- Est-ce que le serveur à des disques rapides (ça peut jouer beaucoup si on utilise du SATA)
- Quelle est la base de donnée ?
- Quels sont les paramètres de la ligne "JAVA_OPTS" du fichier alfresco.bat ou alfresco.sh ?
- Enfin, quel interface utilisez vous ? CIFS ? FTP ? (le second est un peu plus rapide).

maurice

- Est-ce que le CPU est utilisé à 100 % ?

Ce n'est pas certain … on a vu des 212% sur un quadri processeur

- Est-ce que le serveur à des disques rapides (ça peut jouer beaucoup si on utilise du SATA)]

SAS 10K tours
Intel Xeon Dual Core 5120 1.86GHz 1066MHz FSB 2x2MB L2 Cache Processor
2GB PC2-5300 CL5 ECC DDR2 Chipkill FBDIMM 667MHz

- Quelle est la base de donnée ?

MySQL

- Quels sont les paramètres de la ligne "JAVA_OPTS" du fichier alfresco.bat ou alfresco.sh ?

export JAVA_OPTS='-Xms128m -Xmx512m -server'
et export JAVA_OPTS="${JAVA_OPTS} -XX:CompileCommand=exclude,org/apache/lucene/index/IndexReader\$1,doBody -XX:CompileCommand=exclude,org/alfresco/repo/search/impl/lucene/index/IndexInfo\$Merger,mergeIndexes -XX:CompileCommand=exclude,org/alfresco/repo/search/impl/lucene/index/IndexInfo\$Merger,mergeDeletions"

- Enfin, quel interface utilisez vous ? CIFS ? FTP ? (le second est un peu plus rapide).

CIFS

michaelh

Voilà des réponses détaillées comme je les aime

Le CPU n'est pas une bête de course, mais bien suffisant, et le reste du hard tient la route (Avoir un CPU rapide et des disques lents serait bien plus génant).

Deux points malgré tout :

Sur un serveur de production, Alfresco mérite un peu plus de mémoire que celle qui lui est accordée par défaut. Il faudrait faire évoluer les valeurs de la ligne suivante du script de démarrage

export JAVA_OPTS='-Xms128m -Xmx512m -server'‍

Les ressources sont nombreuses sur ce sujet pour que tu te fasses ton idée des bons paramètres, mais je pense qu'augmenter la valeur de Xmx et adapter celle de Xms (qui par convention est souvent 1/3 de Xmx) serait une bonne base de départ.

Ensuite il peut être intéressant de rajouter un paramètre qui sert dans des cas extrêmes de charge et évite quelques "memory error" : -XX:MaxPermSize.

Ce qui donne donne la ligne suivante :

export JAVA_OPTS='-Xms256m -Xmx768m -server -XX:MaxPermSize=128m'‍

Ca devrait mettre la JVM plus à l'aise et faire gagner en réactivité.

Le second point : utiliser FTP pour des imports massifs car il est un peu plus rapide que CIFS pour ce type d'usage (le protocole est moins inefficace).

Il ne faut tout de même pas attendre une explosion des performances. Les imports massifs restent des opérations "lourdes" pour le système et il faut être un peu patient.

maurice

Pourquoi par défaut, Alfresco n'est pas paramétré ainsi si ces modifs aide à rendre Alfresco plus performant ?

En écrivant mon message plus haut, je savais que la question allait venir

On ne peut pas "forcer" les valeurs que j'ai donné par défaut parce qu'en fonction de l'architecture, de la JVM, du serveur d'application, elles pourraient ne pas être adaptées.

On a donc fait le choix de valeurs qui fonctionnent partout. A chacun ensuite de les adapter à son contexte.

Entre nous, elles fonctionnent dans 90 % des cas. Si quelqu'un ne s'en préoccupe pas … c'est souvent qu'il n'en a pas le besoin. Les administrateurs avec une bonne connaissance des serveurs d'applications iront plus loin, mais c'est leur métier.

Je ne suis même pas certain que tu noteras une différence (je ne parle pas de "j'ai l'impression que", mais bien de valeurs mesurées). C'est une astuce qui devrait fonctionner dans ton cas (besoin classique, sur une architecture standard et un serveur de base) mais pas partout.

- Est-ce que tous les formats quelqu'ils soient sont pris en compte par Alfresco ?

Pris en compte, c'est vague

Stockables : oui
Indéxables : non

Par défaut Alfresco gère tous les formats bureautiques "classiques", sauf le format Open-XML de Microsoft (le format de Office 2007) car il n'est pas géré par OpenOffice (qui sert de convertisseur).

- Le délai de transfert/traitement peut-il se réduire significativement si on augmente la RAM du serveur ?

Je ne connais pas le nombre d'utilisateurs connectés en permanence sur ton système, mais comme je suppose que c'est un chiffre assez bas, je ne pense pas que ce soit nécessaire. Il faut s'assurer que le système en manque avant de penser à en ajouter (et pour cela les outils systèmes ne manquent pas).

Il faut penser "usage normal" et pas juste temps d'importation d'un existant. Même si ça prend 10 heures et qu'ensuite tout fonctionne parfaitement, inutile de faire la course à la puissance

- Est-ce que les versions post 2.1 sont plus performantes ?

Pour l'instant on a toujours gagné en performances avec chaque nouvelle version, et c'est aussi le cas avec les versions qui viendront après la 2.1. Cela dit le gain n'est pas non d'un facteur élevé, on le mesure surtout avec des systèmes avec beaucoup d'utilisateurs.

Bref, il faut réserver le "tuning" à des cas particuliers.

maurice

zzzz

maurice

Par défaut Alfresco gère tous les formats bureautiques "classiques", sauf le format Open-XML de Microsoft (le format de Office 2007) car il n'est pas géré par OpenOffice (qui sert de convertisseur).

C'est un peu embêtant car nous avons des utilisateurs qui utilisent Word 2007 et d'autres Word 2003. Et il est logique qu'à terme on upgrade tout le monde en 2007. Alors, est-ce que OpenOffice va gérer bientôt le format Office 2007 (Open-XML) ? J'ai rien trouvé sur le sujet dans le site d'OpenOffice : http://www.openoffice.org/

Je ne connais pas le nombre d'utilisateurs connectés en permanence sur ton système, mais comme je suppose que c'est un chiffre assez bas

En effet, nous avons pour le moment 80 personnes ayant l'accès. Ce chiffre devrait monter rapidement si on ouvre la GED en extranet. Je dirais que 20% se connecte en permanence.

maurice

J'ai dis dans mon précédent post env. 10H pour 50Go ce qui te semblait raisonnable contenu de la configuration de notre serveur.

Après qql tests cette après-midi, en CIFS, j'ai mis 1min pour 20MO (5 fichiers tgz) en upload. Donc, pour 50GO ce serait proche de 40H que de 10H, ce qui semble beaucoup.

Qu'en penses-tu ?

michaelh

En ce qui concerne le support de Open-XML par OpenOffice, je ne sais pas. En attendant au delà d'Alfresco je vous invite à réfléchir à ce qui se passera quand vous enverrez ce type de fichiers à des personnes extérieures à votre société … et à penser à ne pas utiliser ce format sauf obligation

En ce qui concerne la migration … j'ai déjà répondu non ?

maurice

En ce qui concerne la migration … j'ai déjà répondu non ?

Tu as dit que 10H te parraissait normal mais 40H … c'est autre chose, non ?

michaelh

Euh … voui … c'est 4 fois plus

Blague à part, les outils ne manquent pas pour surveiller l'activité d'un système, et trouver le (les) goulot d'étranglement. A défaut de cette analyse, on ne pourra que se limiter à des conjectures qui risquent surtout de te faire perdre du temps à courir après de fausses pistes.

Celà dit je vais me répéter. Dans l'absolu si la migration prenne 10 ou 40 heures mais qu'elle se termine avec 100 % de réussite au final, et que le serveur est réactif en conditions normales, tu vas peut être gagner du temps à … ne pas y passer trop de temps.

berlioux

La date de création n'est pas stockée dans le document à proprement dit, mais sur le système de fichier d'origine. Des solutions existent, mais qui impliquent de mettre fortement les mains dans le moteur je dirais

Pouvez-vous être un peu plus précis ?
Je bute pour ma part sur ce problème depuis pas mal de temps maintenant, sans avoir encore trouvé de méthode totalement satisfaisante…

maurice

Elements de réponses :

http://forums.alfresco.com/viewtopic.php?t=7792&highlight=creation+date

berlioux

Merci pour ce lien.

Je l'avais déjà parcouru, et il ne concerne que l'extraction de métadonnées, pas la conservation des dates présentes sur le filesystem de départ…

michaelh

Pouvez-vous être un peu plus précis ?

Il n'y a pas de méthode totalement satisfaisante … mais il y en a qui fonctionnent.

L'une d'elles est d'aller lire les dates des fichiers d'origine avec un outil externe (un script dans n'importe quel langage) puis insérer ces dates (et au passage les propriétaires éventuellement) directement … dans la base Alfresco (après insertion des éléments).

Ce n'est pas complexe, par contre on a pas le droit à l'erreur quand on travaille à ce niveau

Autre possibilité : travailler avec des fichiers ACP (paquets de contenu Alfresco) qui contiendront les éléments à récupérer + les métadonnées dans un fichier XML généré (par un outil tiers toujours).

C'est déjà plus sûr et il y a quelques bases de travail sur la forge (qui demandent de l'adaptation, d'autant que je ne sois pas certain qu'ils soient maintenus / fonctionnent avec les versions 2.1 et +)

http://forge.alfresco.com/projects/acpgeneratr/
http://forge.alfresco.com/projects/acpcreator/

C'est un besoin assez classique mais pour lequel chacun développe sa solution en fonction de l'endroit où sont stockées les données au départ.

berlioux

Bonjour,

jusqu'à maintenant j'ai travaillé en Acp, avec un résultat correct au final, bien que m'étant heurté au problème de la limitation en taille du format zip 😉

Pour ce qui est de lire les dates et auteurs puis de les injecter dans la base d'Alfresco, vous parlez de webservices j'imagine ?

michaelh

Pour ce qui est de lire les dates et auteurs puis de les injecter dans la base d'Alfresco, vous parlez de webservices j'imagine ?

Non non, je parlais bien de la méthode la plus horrible qui soit, à savoir taper dans la base en SQL. Mais je prenais mes précautions pour que personne ne pense que c'est quelque chose de normal !

Je l'ai vu faire pour de grosses volumétries à reprendre sur des serveurs de fichiers type Windows/Samba.

Après comme disent nos amis Anglophones "Les enfants, ne faites pas ça à la maison"

L'ACP est bien plus propre, même si on est obligé de faire des imports successifs avec des archives d'une taille limitée (en même temps ce n'est pas forcément un mal de travailler par étapes).

Les webservices sont envisageables … j'ai aussi vu dernièrement une autre approche utilisant les webscripts. Bref, les points d'entrée ne manquent pas …

berlioux

Méfiance tout de même avec les imports successifs de fichiers acp.
Lors de l'import, alfresco ouvre le fichier acp et ne le referme pas. Donc avec un très grand nombre de fichiers d'imports, on dépasse les limites système de nombre de fichiers ouverts, et on se retrouve avec une erreur "Too many open files…" dans les logs.

Pour ma part j'ai contourné le problème en faisant un "ulimit -n 8096", et en relançant alfresco après les imports. (J'avais un peu plus de 4900 fichiers d'imports, soit 1 par répertoire de mon arborescence initiale…)

nferay

Bonjour,

Méfiance tout de même avec les imports successifs de fichiers acp.
Lors de l'import, alfresco ouvre le fichier acp et ne le referme pas. Donc avec un très grand nombre de fichiers d'imports, on dépasse les limites système de nombre de fichiers ouverts, et on se retrouve avec une erreur "Too many open files…" dans les logs.

Pour ma part j'ai contourné le problème en faisant un "ulimit -n 8096", et en relançant alfresco après les imports. (J'avais un peu plus de 4900 fichiers d'imports, soit 1 par répertoire de mon arborescence initiale…)

En terme de performance avez vous des retours ? En effet concernant les acp on dit que le temps de restauration est très long.

Est ce qu'avec des acp il est possible de faire des ajouts de fichiers dans une arborescence alfresco qui existe déjà. Je m'explique, j'ai un répertoire repA avec deux fichiers A.doc et B.doc sous alfresco. Est ce que je peux soumettre un ACP qui va ajouter les fichiers C.doc et D.doc dans le repA sous alfresco ?

berlioux

Bonjour,

En terme de performance avez vous des retours ? En effet concernant les acp on dit que le temps de restauration est très long.

Nous avons utilisé les acp pour migrer environ 30go de données dans Alfresco, la partie "import" par alfresco a pris 2-3 heures de mémoire. (Nous avions créé un fichier acp pour chaque dossier de notre arborescence, puis copié le tout vers Alfresco par ftp, avec une règle dans alfresco qui importait tout acp entrant dans le répertoire courant).

Est ce qu'avec des acp il est possible de faire des ajouts de fichiers dans une arborescence alfresco qui existe déjà. Je m'explique, j'ai un répertoire repA avec deux fichiers A.doc et B.doc sous alfresco. Est ce que je peux soumettre un ACP qui va ajouter les fichiers C.doc et D.doc dans le repA sous alfresco ?

Oui, nous l'avons fait également sans problème.

romain

Bonjour,

Pour migrer 30Go de données en ACP, vous avez du scinder les données car le format ZIP ne permet pas de gérer des fichiers de plus de 2Go.

Quelle était la taille des fichiers que vous avez utilisé pour pouvoir migrer 30Go en 3h ?

Merci d'avance