Quelle est la performance attendue d'Obnam? Ou: pourquoi est-ce si lent?

J'ai joué avec obnam ces derniers jours, et bien qu'il semble très prometteur et semble offrir essentiellement tout ce que je voulais dans un outil de sauvegarde, je suis assez déçu de ses performances. En fait, c'est tellement lent, je soupçonne qu'Onamam n'est même pas en faute ici, mais quelque chose dans mon environnement est à l'origine de cela.

Je me demande donc principalement si quelqu'un d'autre utilise obnam ou connaît suffisamment ses composants internes pour peut-être identifier le problème.

D'après ce que j'ai pu voir jusqu'à présent, obnam semble bifurquer un processus gpg individuel pour chaque fichier sauvegardé. À en juger par htop, strace et iostat, la vitesse d'une sauvegarde initiale est principalement limitée par la fourche constante, tandis que le processeur et les lecteurs (aucune mise en réseau n'est impliqué) tournent au ralenti en dessous de 20% d'utilisation.

Ma sauvegarde s'élève à environ 500 000 fichiers avec 170 Gio de données au total. Ainsi, pour chaque exécution de sauvegarde, gpg est bifurqué 500 000 fois. En fait, je ne suis même pas surpris que cela prenne presque une journée entière pour l'exécution initiale et plus de trois heures pour une autre exécution avec la plupart des fichiers inchangés. Mais est-ce vraiment la performance à laquelle les utilisateurs devraient s'attendre? A titre de comparaison: une exécution incrémentielle de rsnapshot (mêmes données, même machine, mêmes lecteurs) prend environ quatre minutes. Certes, aucun chiffrement n'est impliqué, mais cela ne devrait pas être si important.

Donc, pour demander clairement: la machine de tout le monde n'est-elle pas capable d'exécuter gpg (cryptage d'un petit morceau de données) plus de 50 fois par seconde, ce qui fait finalement de obnam un outil presque inhabituellement lent? Ou est-ce juste moi?

(FWIW, ma machine est un Core i5-2500 avec 8 Go de RAM et des disques SSD, exécutant Gentoo. La sauvegarde est effectuée sur un disque dur, mais je n'ai pu observer aucune différence avec la sauvegarde sur le SSD, car il ne s'agit pas d'E / S -lié.)

Voici une bonne lecture sur la façon d'accélérer obnam (peut fonctionner jusqu'à 10 fois plus vite): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Résumé: ajoutez "--lru-size = 1024 --upload-queue-size = 512" à votre ligne de commande ou fichier de configuration. Notez qu'il augmente un peu l'utilisation de la mémoire d'Obnam.

Je pense que j'attaquerais ce problème de deux façons. Pour commencer, j'essaierais de le diagnostiquer moi-même en utilisant les méthodologies suivantes.

1. journaux obnam

Pour commencer, vous pouvez enregistrer des messages obnamcomme ceci:

$ obnam --log obnam.log

Vous pouvez également augmenter le niveau de journalisation via le --log-levelcommutateur pour obtenir plus de détails.

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. Profilage

Vous pouvez également obtenir un profil de ce qui obnamse passe comme suit à partir de cet extrait dans la FAQ du projet :

Si la OBNAM_PROFILEvariable d'environnement contient un nom de fichier, les données de profilage y sont stockées et peuvent être consultées ultérieurement avec obnam-viewprof:

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

Les problèmes de performances qui ne sont pas liés à une configuration particulière peuvent également être observés à l'aide du obnam-benchmark tool.

3. Ouvrez un ticket

Si la performance n'est toujours pas déterminée en faisant une enquête autonome, j'ouvrirais un ticket sur le site Web du projet . D'après ce que j'ai pu rassembler, les développeurs sont quelque peu réactifs et ils seraient probablement les meilleurs pour éliminer les problèmes avec leur projet.

obnamsemble utiliser uniquement SFTP, il devrait donc être assez évident de savoir ce qui cause le problème. J'envisagerais également de baser les performances SFTP en soi afin que vous puissiez voir quel devrait être le maximum théorique avec votre connexion système + réseau avant d'essayer d'obtenir ces informations des obnamtests eux-mêmes.

Points de données supplémentaires

Trouvé cet article de blog où l'auteur a fait une comparaison de plusieurs options dans cette catégorie. L'article est intitulé: Comparaison de rsnapshot et obnam pour les sauvegardes volumineuses planifiées .

L'article a mis en évidence des performances très médiocres, OMI, obnamqui semblent correspondre à ce que vous décrivez.

performance obnam

Après avoir complètement sauvegardé / home (ce qui a pris plusieurs jours!), Une nouvelle exécution, plusieurs jours plus tard, a pris (chronométrage par la commande Linux time):

3443706 fichiers sauvegardés, 94,0 Gio téléchargés en 127h48m49s à 214,2 Kio / s de vitesse moyenne830 fichiers; 1,24 Gio (0 B / s) réel 7668m56.628s utilisateur 4767m16.132s sys 162m48.739s

À partir du fichier journal obname:

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

Donc: ~ 5 jours pour sauvegarder ~ 100 Go de données modifiées… La charge n'était pas élevée sur les machines, ni en termes de CPU, ni en termes de RAM. L'utilisation du disque dans / backups / backup_home était de 5,7T, l'utilisation du disque de / home était de 6,6T, il y a donc un peu de déduplication, semble-t-il.

performances rsnapshot

Une sauvegarde complète de / home vers (selon le fichier journal):

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

Donc: ~ 1,5 jours pour une sauvegarde complète de 6,3 To. Une sauvegarde incrémentielle un jour plus tard a pris:

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

Donc: 15 minutes ... et les données modifiées s'élevaient à 21 Go.

Pas aussi complet mais mentionne que l'un des inconvénients obnamest qu'il est très lent par rapport à attic.

Obnam pros:

• bien documenté
• liste de diffusion active
• forfaits disponibles

Obnam contre:

• très lent
• grandes sauvegardes

Avantages du grenier:

• sauvegardes beaucoup plus petites (même sans déduplication)
• bien meilleure déduplication
• Plus vite

Contre grenier:

• format de référentiel non documenté
• pas une grande communauté d'utilisateurs

Certaines données de test sont affichées, ce qui semble indiquer que obnamc'est vraiment très lent.

Du SSD local au HD distant, via une connexion wifi moyenne:

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

Références

• Obnam peaufine son article de blog

La configuration par défaut d'Obnam (à partir du 2015-02-08) ne fonctionne pas bien pour sauvegarder des répertoires avec un grand nombre de petits fichiers. J'ai eu exactement le même problème que celui mentionné ci-dessus.

La solution pour moi était d'ajouter --lru-size = 8192 --upload-queue-size = 8192 à la ligne de commande. Cela a résolu le problème et transformé un frustré en un utilisateur Obnam très heureux. (J'ai maintenant ces paramètres dans mes fichiers de configuration standard.)

Malheureusement, le tutoriel d'Obnam ne mentionne pas d'emblée l'importance de ces paramètres. La FAQ donne plus de détails. La définition des paramètres de performances est vraiment obligatoire sur les systèmes contenant de nombreux petits fichiers.