Owncloud : optimiser la vitesse de transfert des gros fichiers

closeCet article a été publié il y a 4 ans 11 mois 2 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

fuploadJe commence à avoir un peu de recul sur la mise en pratique d’Owncloud dans divers contextes d’utilisation professionnelle. Le dernier en date m’a permis de mettre le doigt sur un « détail » important à connaître.

Le cas en question consistait à synchroniser les fichiers stockés sur un serveur motorisé par Openmediavault vers une instance Owncloud afin de permettre à mon client de mettre à disposition des fichiers, mais aussi de disposer d’une sauvegarde externalisée.

J’ai utilisé la version « ligne de commande » du client de synchronisation d’Owncloud afin de lancer les synchronisations directement depuis le serveur. Openmediavault utilise une version 7 de Debian. J’ai fait l’installation du client Owncloud de façon assez classique en ajoutant les dépôts pour Debian 7. À l’installation on récupère pas mal de dépendances, mais rien de catastrophique. L’utilisation de la commande owncloudcmd est documentée sur le site du projet.

C’est environ 700 Go de données qu’il s’agissait de synchroniser. Ayant accès à une fibre de 300 Mbps, je n’étais pas trop inquiet. J’avais estimé à environ 6/7 heures la durée de la synchronisation initiale.

Lancé durant un week-end afin de disposer de toute la bande passante, je constate au bout de 10 heures que le transfert n’est pas terminé. Seuls 450 Go ont été transférés. Je laisse passer encore quelques heures pour constater que la synchronisation n’a avancé que de quelques dizaines de Go. Fatalement, coup de stress, je commence à investiguer.

Premier constat, la machine virtuelle où est installé Owncloud mouline furieusement. Le serveur web et la base de données tournent à plein régime. J’augmente les ressources allouées à la machine virtuelle qui bien évidemment ne fait que mouliner davantage. Le plus suspect est qu’il n’y a que très peu de trafic réseau.

Mes investigations se portent sur le client de synchronisation et son historique. Je constate alors que ce dernier envoi des rafales de requêtes pour certains fichiers. Il s’agit de gros fichiers. En l’occurrence des rushs de vidéo. Il y a là des fichiers qui font jusqu’à 14 Go pièces. De belles bêtes 🙂 !

En creusant un peu, je découvre le fonctionnement « intime » du client de synchronisation. Lorsque les fichiers sont gros (disons plus de 5 à 10 Mo), le client les saucissonne pour les envoyer dans un répertoire de cache sur le serveur. Ces petits fichiers portent le doux nom de « chunk ». Par défaut, leur taille est de 5 Mo. L’objectif est de permettre une reprise en cas de coupure du transfert d’un gros fichier. Une fois tous transférés, les fichiers sont réassemblés sur le serveur pour constituer le fichier final. Sur le serveur Owncloud, les fichiers partiellement transférés portent une extension .part et grossissent par à-coups.

Mais, lorsque l’on dispose d’une liaison haut débit, cette taille de fichier n’est plus adaptée. À 5 Mo, le transfert des données prend environ 0,20 seconde. De fait, le client de synchronisation passe plus de temps à établir la connexion avec le serveur Owncloud, lui donner quelques informations qu’il enregistre dans la base de données, qu’à faire le transfert. Résultat le transfert devient épouvantablement lent au regard des possibilités de la liaison. C’est un souci que j’ai retrouvé sur les forums d’Owncloud à plusieurs reprises.

La solution consiste à modifier la taille par défaut du chunk pour privilégier le transfert de données par rapport au dialogue entre le client et le serveur.

Pour cela, vous devez sous GNU/Linux positionner des variables d’environnement. J’ai fait cela dans le fichier .profile de l’utilisateur qui lance la commande de synchronisation.

export OWNCLOUD_CHUNK_SIZE=5242880
export OWNCLOUD_MAX_PARALLEL=3

La première variable vous l’aurez compris permet de définir (en octets) la taille du chunk. Le second définit le nombre de connexions parallèles maximum pour le transfert de fichiers. La valeur par défaut est de 3.

Dans mon cas, j’ai donc poussé la taille du chunk à 100 Mo et monté la valeur de la seconde à 5. Résultat, 3 heures plus tard le transfert était terminé. La charge du serveur est restée relativement faible.

À noter que j’ai quand même dû faire le ménage dans le dossier cache sur le serveur. En changeant la valeur, visiblement le client à recommencé les transferts en cours. Il restait donc plein de fichiers de 5 Mo que j’ai supprimé manuellement.

Ces variables doivent fonctionner aussi pour le client de synchronisation traditionnel, bien que je n’en ai pas fait le test. De même, il doit être possible sous Windows de spécifier ces variables d’environnement, là encore je vous laisse vous dépatouiller avec ce dernier 🙂

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

10 réponses

  1. fredix dit :

    Plutôt bizarre le fonctionnement de owncloud, car un protocole vieux de 30 ans comme ftp gère le resume sans génèrer des chunks.

  2. bobricard dit :

    Ownlcoud pour de la sauvegarde, il faut avoir confiance. Avec la version 7, j’ai perdu régulièrement des fichiers sans raison apparente. Depuis, je n’utilise plus owncloud mais syncthing qui permet une fiabilité accrue et permet de faire un vrai maillage.

  3. Bonob0h dit :

    Et voilà il commence a nous allécher et nous laisse a la fin nous dépatouiller 😉
    Bon prince je t’ai envoyé les copie écran du client Win pour que tu complète ;)))

  4. @fredix : La synchro du client Owncloud passe par du http/https, pas du FTP. Difficile de comparer donc. De plus en FTP, faut que le serveur soit configuré comme il faut pour le supporter.

  5. @bobricard : j’utilise Owncloud en prod pour mes clients sur mon hébergement que depuis la v8.0 Ou du moins la v7 n’a pas duré longtemps. Je touche du bois, mais personne ne m’a signalé de disparition de fichiers que l’on ait pas pu expliquer. De plus je sauvegarde les données d’Owncloud, donc bretelles et ceintures…
    Je ne connaissais par Syncthing, ça mérite un test effectivement 🙂
    @Bonob0h : Merci ! Comme expliqué par mail c’est pas tout à fait ça qu’il faudrait 😉

  6. fredix dit :

    je confirme j’utilise syncthing et ca marche super bien. C’est juste un binaire static (merci Golang) qui a une interface web, et qui se met à jour tout seul à chaque version.
    Je l’utilise meme sur un ARM chez https://www.scaleway.com pour synchro mon blog : http://fredix.xyz/2014/10/hugo-syncthing/

  7. Il y a moyen de gérer des droits d’accès dans le cas d’une utilisation partagée entre plusieurs personnes ?

  8. fredix dit :

    Je ne crois pas, c’est une synchro de répertoires entre instance par machine. Pour une utilisation partagée par plusieurs utilisateurs il faut voir avec seafile https://www.seafile.com/en/home/

  9. @fredix : comme Owncloud gère le partage entre utilisateur des fichiers et dossier, aller sur Seafile ou Pydio n’apporte pas forcément grand chose. Mes clients apprécient les autres fonctions d’Owncloud dont notamment le partage d’agenda et intégration si besoin d’un webmail comme Rainloop.

  10. FTP ne faisait pas un peu le même boulot ? En tout cas, de ce que j’ai entendu auparavant, Owncloud n’est pas si terrible que ça mais il y a eu des amis qui se sont plaint de perte de fichiers également. Je ne sais pas si c’est due à une mauvaise manipulation ou bien à un défaut d’Owncloud. Mais j’attends d’avoir plus de garantie et de faire plus de comparaison avant de m’y lancer.