Owncloud : optimiser la vitesse de transfert des gros fichiers

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

Je 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 🙂