Pourquoi rsync est plus rapide que NFS?

40

Il y a quelques jours, j'ai remarqué quelque chose d'assez étrange (du moins pour moi). J'ai lancé rsync en copiant les mêmes données et en les supprimant ensuite vers le montage NFS, appelé /nfs_mount/TEST. Ceci /nfs_mount/TESTest hébergé / exporté nfs_server-eth1. Le MTU sur les deux interfaces réseau est 9000, le commutateur entre prend également en charge les trames jumbo. Si je le fais, rsync -av dir /nfs_mount/TEST/j'obtiens une vitesse de transfert réseau de X Mbps. Si je le fais, rsync -av dir nfs_server-eth1:/nfs_mount/TEST/j'obtiens une vitesse de transfert réseau d'au moins 2X MBps. Mes options de montage NFS sont nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Ligne de fond: les deux transferts passent par le même sous-réseau, les mêmes fils, les mêmes interfaces, lisent les mêmes données, écrivent dans le même répertoire, etc. La seule différence est via NFSv3, l'autre sur rsync.

Le client est Ubuntu 10.04, le serveur Ubuntu 9.10.

Comment se fait-il que rsync soit beaucoup plus rapide? Comment faire en sorte que NFS corresponde à cette vitesse?

Merci

Edit: notez que j’utilise rsync pour écrire sur le partage NFS ou sur SSH sur le serveur NFS et y écrire localement. Je fais les deux fois rsync -av, en commençant par le répertoire de destination clair. Demain je vais essayer avec une copie simple.

Edit2 (informations supplémentaires): La taille du fichier est comprise entre 1 Ko et 15 Mo. Les fichiers sont déjà compressés, j'ai essayé de les compresser davantage sans succès. J'ai fait un tar.gzfichier à partir de ça dir. Voici le motif:

  • rsync -av dir /nfs_mount/TEST/ = transfert le plus lent;
  • rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= le plus rapide rsync avec les trames jumbo activées; sans trames jumbo est un peu plus lent, mais toujours nettement plus rapide que celui directement à NFS;
  • rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = environ le même que son équivalent non-tar.gz;

Tests avec cpet scp:

  • cp -r dir /nfs_mount/TEST/= légèrement plus rapide que rsync -av dir /nfs_mount/TEST/mais toujours significativement plus lent que rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
  • scp -r dir /nfs_mount/TEST/= le plus rapide dans l'ensemble, légèrement dépassé rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
  • scp -r dir.tar.gz /nfs_mount/TEST/ = environ le même que son équivalent non-tar.gz;

Conclusion, basée sur ces résultats: Pour ce test, il n'y a pas de différence significative si vous utilisez tar.gz gros fichier ou plusieurs petits. Les trames Jumbo activées ou désactivées ne font également presque aucune différence. cpet scpsont plus rapides que leurs rsync -avéquivalents respectifs . L'écriture directe sur le partage NFS exporté est nettement plus lente (au moins deux fois) que l'écriture dans le même répertoire sur SSH, quelle que soit la méthode utilisée.

Les différences entre cpet rsyncne sont pas pertinentes dans ce cas. J'ai décidé d'essayer cpet scpde voir si elles montrent le même motif et elles le font - différence 2X.

Comme je l’utilise rsyncou cpdans les deux cas, je ne comprends pas ce qui empêche NFS d’atteindre la vitesse de transfert des mêmes commandes sur SSH.

Comment se fait-il que l'écriture sur le partage NFS est deux fois plus lente que l'écriture au même endroit sur SSH?

Edit3 (NFS serveur / etc / exports) Options: rw,no_root_squash,no_subtree_check,sync. / Proc / mounts spectacles du client: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Merci à tous!

grs
la source
Est-ce que cela devrait être le même résultat pour beaucoup de petits fichiers et un gros fichier?
Xiè Jìléi
@notpeter - a ajouté les options de l'article d'origine. Merci!
grs
Je me rends compte que la question est plutôt ancienne, mais une différence majeure entre SCP et rsync qui explique une légère différence de temps de transfert est la somme de contrôle de transfert automatique de fichier effectuée pour indiquer que le fichier a été transféré correctement. Cela diffère de l'option -c de rsync qui utilise une somme de contrôle pour valider si un fichier a été mis à jour entre des hôtes. Si vous ne copiez que de nouveaux fichiers, ceux-ci n'entrent pas en lecture.
Rowan Hawkins

Réponses:

20

Ce n’est peut-être pas une vitesse de transfert plus lente, mais une latence d’écriture accrue. Essayez de monter le partage NFS asynchrone au lieu de synchroniser et voyez si cela réduit l'écart de vitesse. Lorsque vous rsynchronisez sur ssh, le processus rsync distant écrit de manière asynchrone (rapidement). Toutefois, lors de l'écriture sur le partage nfs monté de manière synchrone, les écritures ne sont pas confirmées immédiatement: le serveur NFS attend d'avoir frappé le disque (ou plus probablement le cache du contrôleur) avant d'envoyer la confirmation au client NFS que l'écriture a réussi.

Si 'async' résout votre problème, sachez que si quelque chose se passe sur le serveur NFS en cours d'écriture, vous risquez de vous retrouver avec des données incohérentes sur le disque. Tant que ce montage NFS n'est pas le stockage principal pour cette (ou toute autre) donnée, tout ira bien. Bien sûr, vous seriez dans le même bateau si vous débranchiez le serveur nfs pendant / après l'exécution de rsync-over-ssh (par exemple, rsync renvoie «terminé», le serveur nfs plante, les données non validées dans le cache d'écriture sont maintenant perdues. laissant des données incohérentes sur le disque).

Bien que ce ne soit pas un problème avec votre test (synchronisation de nouvelles données), sachez que rsync sur ssh peut imposer d'importantes demandes de CPU et d'E / S sur le serveur distant avant le transfert d'un seul octet lors du calcul des sommes de contrôle et de la création de la liste des fichiers devant être transférés. mis à jour.

notpeter
la source
1
Je pense que cette réponse est la bonne. Si les supports (disques) des deux ordinateurs sont comparables (même configuration RPM / bande passante / RAID), vous pouvez avoir une bonne idée de savoir si c'est le cas en effectuant l'opération inverse: 'rsync -av / nfs_mount / TEST / dir 'Sinon, désactiver la synchronisation et l'essayer est le moyen de tester.
Slartibartfast
J'ai fait des tests rapides avec sync vs async et je pense que cette réponse a de grandes chances d'être la bonne. Le choix asynchrone réduit considérablement l’écart, mais il est toujours un peu plus lent que celui de SSH. Je vais faire d'autres tests et vous laisser savoir. Merci beaucoup!
grs
3
Mise à jour: mes nouveaux tests ont montré une différence significative en termes de vitesse de synchronisation par rapport à l'option d'exportation asynchrone NFS. Avec NFS monté en asynchrone, rsync -av dir.tar.gz /nfs_mount/TEST/j'ai obtenu à peu près la même vitesse de transfert qu'avec rsync -av dir nfs_server-eth1:/nfs_mount/TEST/. Je vais marquer cette réponse comme étant correcte, mais je suis curieux de pouvoir améliorer davantage la configuration. Merci! Bravo notpeter!
grs
22

NFS est un protocole de partage, tandis que Rsync est optimisé pour les transferts de fichiers. de nombreuses optimisations peuvent être effectuées lorsque vous savez a priori que votre objectif est de copier les fichiers aussi rapidement que possible au lieu de leur fournir un accès partagé.

Cela devrait aider: http://en.wikipedia.org/wiki/Rsync

Massimo
la source
2
Si vous connaissez les données à l’avance (ce que vous faites habituellement), vous pouvez désactiver la compression de manière sélective avec l’option -e "ssh Compression=no"permettant d’obtenir une vitesse de transfert éventuellement plus rapide. Cela l'empêchera de compresser des fichiers éventuellement déjà compressés. J'ai remarqué une accélération à plusieurs reprises.
LSD
5
@lsd - La compression ssh est généralement désactivée par défaut et n'est pas recommandée pour rsync. Permettre rsync de compresser les données avec les options -z, --compress-levelet --skip-compressira mieux tha performance avec un transport comprimé.
JimB
5

Rsync est un protocole de fichier qui transfère uniquement les bits modifiés entre les fichiers. NFS est un protocole de fichier de répertoire distant qui gère tout à chaque fois ... un peu comme un SMB. Les deux sont différents et à des fins différentes. Vous pouvez utiliser Rsync pour transférer entre deux partages NFS.

pcunite
la source
6
Je me sens un peu mal en vous votant parce que vous n'avez rien dit techniquement de mal, mais il ne semble pas que vous ayez ajouté quelque chose à la discussion, et vous êtes arrivé après que des informations beaucoup plus spécifiques aient été mises à disposition. En outre, d'après son message, il semble que l'auteur était au courant de ces choses.
Slartibartfast
Je pensais être le deuxième poste et le premier à mentionner que tous deux étaient des protocoles ayant des objectifs différents. Ca va, je pensais que la première édition de la question était un peu stupide.
pcunite
3

C'est intéressant. Une possibilité que vous n'avez peut-être pas envisagée est le contenu / type de fichier que vous transmettez.

Si vous avez des groupes de petits fichiers (p. Ex. Des courriers électroniques dans des fichiers individuels), l'efficacité de NFS peut être décevante car vous n'utilisez pas le MTU complet (peut-être que cela est moins probable avec TCP sur UDP).

Sinon, si vous avez des fichiers / données hautement compressibles, des processeurs rapides et un réseau qui n’a pas tout à fait la vitesse du processeur (*), vous pouvez obtenir de l’accélération uniquement grâce à la compression implicite sur le lien ssh.

Une troisième possibilité est que les fichiers (ou une version de ceux-ci) existent déjà dans la destination. Dans ce cas, l'accélération serait due au fait que le protocole rsync vous enregistre lors du transfert des fichiers.

(*) Dans ce cas, par «vitesse», je parle du débit auquel le processeur peut compresser les données par rapport au débit que le réseau peut transmettre, par exemple, il faut 5 secondes pour envoyer 5 Mo sur le fil, mais le processeur peut compresser ces 5 Mo en 1 Mo en 1 seconde. Dans ce cas, le temps de transmission des données compressées serait légèrement supérieur à 1 seconde, alors que les données non compressées durent 5 secondes.

Slartibartfast
la source
Très bien! Les fichiers que je teste contiennent de nombreuses petites images. Ils varient en taille. Je dois vérifier si je peux les compresser davantage. Les fichiers n'existent certainement pas à la destination, car je pars de zéro à chaque fois. Demain, je ferai des tests avec simple cp -rvs rsync, puis je compresserai les fichiers pour en faire des fichiers plus volumineux afin de tirer parti du MTU. Merci!
grs
1

J'utilise aussi -e "ssh Ciphers = arcfour" pour augmenter le débit.

ThorstenS
la source
1
Besoin d'un "-o". c'est-à-dire: "rsync -va -e" ssh -o Ciphers = arcfour "destination de la source: / destination /"
Pete Ashdown le
1

Si votre objectif est simplement de copier tous les fichiers d'un endroit à un autre, tar / netcat sera l'option la plus rapide. Si vous savez que vos fichiers contiennent beaucoup d'espaces (zéros), utilisez l'option -i.

SOURCE: tar cvif - / chemin / vers / source | nc DESTINATION PORTNUM DESTINATION: cd / chemin / à / source && nc -l PORTNUM | tar xvif -

si vous savez que vos données sont compressibles, utilisez la compression sur vos commandes tar -z -j -Ipixz

Je suis un fan de pixz .. parallel xz, il offre une excellente compression et je peux régler le nombre de processeurs dont je dispose sur la bande passante du réseau. si j'ai une bande passante plus lente, j'utiliserai une compression plus élevée, donc j'attendrai plus le processeur que le réseau .. si j'ai un réseau rapide, j'utiliserai une compression très basse:

SOURCE: tar cvif - / chemin / vers / source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ignorez les zéros, compression pixz de niveau 2 à l'aide de 12 cœurs de processeur. DESTINATION: nc -l PORTNUM | tar -Ipixz -xvif

si vous réglez correctement le niveau et les cœurs de compression, en fonction de votre ensemble de données, vous devriez être en mesure de maintenir le réseau saturé et de faire suffisamment de compression pour que le goulot d'étranglement devienne le disque (généralement côté écriture si les systèmes de disques en lecture et en écriture sont compatibles). le même).

Quant à rsync, je pense qu’il saute des zéros de la même manière que tar, avec cette option, de sorte qu’il transmet moins de données que NFS. NFS ne peut pas émettre d'hypothèses sur les données et doit donc transmettre chaque octet en même temps que la surcharge de protocole NFS. rsync a des frais généraux ..

netcat n'en a pratiquement aucun .. il va envoyer des paquets TCP complets qui ne contiennent que des données qui vous intéressent.

avec netcat, comme avec scp, vous devez envoyer toutes les données source à tout moment, vous ne pouvez pas être sélectif comme avec rsync, ce qui ne convient pas aux sauvegardes incrémentielles ou ce genre de choses, mais c'est bon pour la copie de données ou l'archivage.

utilisateur3186751
la source
0

Avez-vous une configuration de verrouillage de fichier sur le nfsshare? Vous pourriez obtenir beaucoup plus de performances si cela était désactivé.

n8whnp
la source
Comment puis-je savoir s'il est activé ou non? Ceci ici: docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_02.htm suggère que NFS v3 ne dispose pas de fonctionnalités de verrouillage de fichiers.
grs
-1

Je suppose que la vitesse accrue est au moins en partie due à "rsync src host: / path" générant un processus local sur la machine distante pour l'envoi / la réception, ce qui réduit effectivement votre E / S de moitié.

Jimmy Selgen Nielsen
la source