Journal Considération sur l'emploi de rsync

Posté par (page perso) .
Tags : aucun
15
15
jan.
2009
Cher journal,

j'ai du récemment faire des tests avec rsync pour savoir quel était le moyen de l'utiliser qui allait utiliser le moins de temps (et donc de bande passante) possible.

Le but est d'envoyer régulièrement des fichiers textes qui changent souvent mais peu (des dumps .sql). Alors faut-il les envoyer en .sql ou en .sql.gz? Et chez nous, nous utilisons la compression de rsync (-z) pour les transferts via internet mais pas pour les transferts sur le LAN (switch gigabit).

Aussi, j'ai entrepris de faire quelques tests avec et sans compression, en envoyant un fichier puis sa version un peu modifiée (dumpée qques heures plus tard). J'ajoute que le test a été fait sur des machines debian stable 4.0 etch, avec rsync version 2.6.9 protocol version 29. J'ai utilisé deux fichier de taille différentes:
  • 1.sql de 18986153 octets
  • 2.sql de 38907957 octets
Si je gzip ces fichiers normalement, ils font:
  • 1.sql de 974669 octets, soit ~5% de l'original
  • 2.sql de 5622484 octets, soit ~15% de l'original
Si je les gzip avec l'option --rsyncable, j'arrive à:
  • 1.sql de 1052710 octets, soit ~108% de l'autre gz
  • 2.sql de 5804575 octets, soit ~103% de l'autre gz

Voyons maintenant quel est le speedup et combien d'octets sont envoyés au second envoi.

Sans compression rsync (-av):
  • 1.sql 278.19; 42028 sent
  • 2.sql 33.33; 1123604 sent
  • 1.sql.gz 10.72; 84947 sent
  • 2.sql.gz 1.33; 4209490 sent
  • 1.sql.gz (avec --rsyncable) 31.02; 27728 sent
  • 2.sql.gz (avec --rsyncable) 8.06; 706105 sent

Ici, on le voit, le meilleur moyen est d'utiliser un .gz avec --rsyncable. Pour autant que la bande passante soit une priorité tout en utilisant pas la compression rsync (-z).

Plus intéressant, voyons les mêmes tests, avec la compression rsync (-avz):
  • 1.sql 602.18; 5309 sent
  • 2.sql 198.33; 152437 sent
  • 1.sql.gz 11.16; 81335 sent
  • 2.sql.gz 1.33; 4208162 sent
  • 1.sql.gz (avec --rsyncable) 35.16; 23730 sent
  • 2.sql.gz (avec --rsyncable) 8.14; 698166 sent

Là, il n'y a pas photo, l'utilisation de fichiers gzippés augmente considérablement la taille du transfert! L'option --rsyncable réduit bien le transfert par rapport au .gz normal, mais le .sql est largement devant.

Notons aussi que, compression rsync (-z) ou pas, l'envoi d'un .gz normal est quasi identique; il renvoie quasi tout le fichier dans les deux cas.

Moralité : faut pas envoyer des .gz de fichiers texte en utilisant la compression rsync, cela rallonge drôlement la taille et donc le temps du transfert.
  • # merci

    Posté par (page perso) . Évalué à 5.

    Et bien merci pour test tests, ca fait economiser du temps de note coté :)
  • # surcompression

    Posté par (page perso) . Évalué à 2.

    tu veux dire que tu compresses un truc déjà compressé ?
    logiquement le fchier devient plus gros...

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: surcompression

      Posté par (page perso) . Évalué à 1.

      Non, enfin pas totalement : c'est un fichier compressé qui passe dans un canal lui aussi compressé. Dans les chiffres, c'est un poil de cul plus petit que un fichier compressé dans un canal non-compressé (84947 contre 81335 pour 1.sql.gz)

      La gelée de coings est une chose à ne pas avaler de travers.

      • [^] # Re: surcompression

        Posté par . Évalué à 2.

        Rsync transmet aussi les tables/hashs de différences. Un canal compressé en réduit la taille.
        Un --whole-file devrait ne transmettre que la liste des fichiers.
  • # Variation

    Posté par . Évalué à 1.

    Je tenterais une variation à coup de diff/patch sur les nouveau/ancien fichier puis passage dans lzma pour la compression du patch et envois par un transfert ftp ou netcat.

    Je pense que cela devrait être le moins consommateur de bande passante.

    "La première sécurité est la liberté"

    • [^] # Re: Variation

      Posté par . Évalué à 10.

      A mon avis, c'est typiquement ce qu'il ne faut pas faire : réinventer la roue.
      Ce que tu viens de décrire doit être en gros ce que fait rsync.
      • [^] # Re: Variationrs

        Posté par . Évalué à 2.

        rsync compare un fichier source et un fichier sur un autre poste sans doute en utilisant des checksums, les 2 fichiers avant/après ne sont donc pas sur la même machine.

        De plus, la compression utilisé est gzip, légère mais bien moins efficace que lzma.

        Bref, dans ce cas, cela me parait bien plus optimal pour ce cas d'utilisation.

        "La première sécurité est la liberté"

        • [^] # Re: Variationrs

          Posté par (page perso) . Évalué à 2.

          « rsync compare un fichier source et un fichier sur un autre poste sans doute en utilisant des checksums, les 2 fichiers avant/après ne sont donc pas sur la même machine. »

          En fait, le comportement par défaut de rsync c’est de regarder la date et/ou la taille du fichier pour voir la différence. Une option supplémentaire spécifie si l’on veut faire une différence sur les checksums : ça à l’avantage d’être plus fiable mais au détriment de la vitesse.
      • [^] # Re: Variation

        Posté par (page perso) . Évalué à 1.

        > A mon avis, c'est typiquement ce qu'il ne faut pas faire : réinventer la roue.

        Oui.

        > Ce que tu viens de décrire doit être en gros ce que fait rsync.

        Pas tout à fait. La difficulté de rsync, c'est qu'il ne veut envoyer que le patch, mais que pour calculer le diff correctement, il faudrait avoir les deux copies sur la même machine, et ça, justement, c'est ce qu'on cherche à faire. Du coup, rsync se débrouille en coupant le fichier en morceaux, envoyant les checksums des différents bouts, ... mais c'est quand même sous-optimal.

        Une solution qui fait des diffs en local, et qui envoie le patch, ça existe déjà aussi, c'est ce que fait à peu près n'importe quel gestionnaire de versions. Donc, une solution assez simple serait d'utiliser par exemple Git, un commit sur la machine distante, un "pull" et le tour est joué.
        • [^] # Re: Variation

          Posté par . Évalué à 1.

          Oui, mais rien ne garantit à rsync d'avoir toujours une copie de l'ancienne version du fichier en local !
          Alors que pour un SVN/Git/whatever, la copie de travail locale garantit cela.
          • [^] # Re: Variation

            Posté par . Évalué à 2.

            Justement pas, la copie de travail locale c'est celle que le développeur a modifié, donc il faut renvoyer tout le fichier au serveur pour que lui l'enregistre efficacement en faisant des diff.
            • [^] # Re: Variation

              Posté par (page perso) . Évalué à 1.

              Tu connais beaucoup de gestionnaires de versions qui ont besoin d'envoyer une copie entière au serveur pour faire le diff ? (à part CVS, je n'en connais pas. SVN a les .svn/prop-base/, Git, Mercurial, Bazaar ont une copie de l'historique en local dans leur mode de fonctionnement classique, ...).
              • [^] # Re: Variation

                Posté par . Évalué à 1.

                Ben justement, je ne connais que CVS effectivement.
                Ça veut dire que pour les autres il faut prévoir le double de place pour la copier locale?
                • [^] # Re: Variation

                  Posté par . Évalué à 2.

                  Comment ça, le "double de place" ?
                  La copie locale occupe autant de place que le dépôt sur le serveur (modulo les différences, locales ou distantes, apportées depuis la dernière synchronisation).
                  • [^] # Re: Variation

                    Posté par (page perso) . Évalué à 2.

                    Non, pour SVN, il faut bien "double place", i.e. pour un arbre de travail de 1Mo, il faut un peu plus de 2Mo pour le stoquer en local. Ce qui est bête, c'est que les fichiers "base" ne soient pas compressés.

                    Pour Git, par exemple, c'est carrément tout l'historique qui est dupliqué en local, mais suffisament bien compressé pour prendre en général moins de place que l'arbre de travail.

                    En pratique, en général, on s'en fout un peu : l'arbre de travail est un truc qui n'a pas besoin de beaucoup d'attention au niveau sauvegarde, et vu le prix des disques durs, ... (par contre, l'archive, elle, elle est stoquée sur des disques qui coûtent cher en général, et on est bien content qu'elle soit compressée comme il faut).
                    • [^] # Re: Variation

                      Posté par . Évalué à 2.

                      Je ne comprends pas ce qui, en local, peut entrainer une consommation de place supérieure à la place consommée sur le serveur ?
                      Parce que moi, c'est ainsi que j'ai compris la question !
                      • [^] # Re: Variation

                        Posté par (page perso) . Évalué à 2.

                        Si tu as 1 fichier, 1 révision. Disons un .jpg de 2Mo.

                        Sur le serveur, tu as 1 copie de ce fichier, dans la seule révision. Le dépôt fera ~2Mo. Dans la copie locale, tu as le fichier sur lequel tu travailles, plus le fichier base caché dans un .svn/, donc tu as le fichier en double.

                        Testé à l'instant :

                        $ du -sh *
                        3.8M checkout
                        2.0M repo
                        $ du -sh checkout/dsc04507.jpg checkout/.svn/text-base/dsc04507.jpg.svn-base
                        1.9M checkout/dsc04507.jpg
                        1.9M checkout/.svn/text-base/dsc04507.jpg.svn-base
  • # Pas tout compris

    Posté par . Évalué à 3.

    Bonjour,

    J'aurais besoin de quelques éclaircissements sur les valeurs indiquées. Exemple :
    # 2.sql.gz 1.33; 4209490 sent

    le 1.33 represente-t-il ne nombre de secondes ?

    Si oui, cela veut dire (si j'ai compris) que le transfert est plus important avec un gzip classique mais plus rapide, et que le gzip --rsyncable. et que le gzip --rsyncable est plus léger mais plus long...

    Maintenant, si j'ai juste je me demande quelle peut-être l'utilisation CPU lors des différentes opérations, aussi bien côté client que serveur.

    (Et si j'ai rien compris du tout, peux-tu m'aider à comprendre)
    • [^] # Re: Pas tout compris

      Posté par (page perso) . Évalué à 4.

      1.33 est le 'speedup'. Si c'était 1.00 il n'y aurait pas de gain (1:1) 1.33 signifie qu'il a été un poil plus petit (et plus rapide donc) que s'il avait envoyé tout le fichier (il a renvoyé environ 75% du fichier). Un speedup de 602.18 signifie qu'il a été plus rapide sur un facteur 1:602.18 (et n'a donc dû renvoyer qu'une infime partie du fichier).

      Côté charge CPU, ajouter de la compression à rsync (-z) fait naturellement monter le load sur *les deux machines* car il faut compresser d'un côté et décompresser de l'autre. C'est pourquoi je mettais que, chez nous en tous cas, nous n'utilisons pas cette compression pour les transferts internes car le gain en bande passante est moins plus que gâché par la charge CPU.

      Note que nous ne payons naturellement pas la bande passante à l'interne. Par contre, pour les transferts via internet, nous la payons; c'est pourquoi nous recherchons une efficacité de ce côté.

      La gelée de coings est une chose à ne pas avaler de travers.

      • [^] # Re: Pas tout compris

        Posté par . Évalué à 1.

        OK, c'est la notion de 'speedup' que je ne comprenais pas, maintenant tout est beaucoup plus clair. Merci pour cet article intéressant.
        • [^] # Re: Pas tout compris

          Posté par (page perso) . Évalué à 2.

          Oui, moi aussi j'ai pas pigé au début. Il faut voir qu'ici la notion de vitesse est la vitesse d'exécution, pas forcément la vitesse de transmission.

          La gelée de coings est une chose à ne pas avaler de travers.

  • # rsync 3 protocol v30

    Posté par (page perso) . Évalué à 2.

    Par ailleurs, je conseille plus que hyper vivement l'utilisation du rsync de backports de lenny sur etch : rsync 3 avec son protocole en version 30 apporte quelques améliorations notables, comme le fait de ne plus avoir à transférer toute la liste des fichiers avant de commencer les transferts ...

    ce backport requiert les packages de lenny base-file et rsync. très léger.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.