Pourquoi rsync est plus rapide que NFS?

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!

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.

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

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.

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.

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

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.

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

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é.