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 exécuté rsync en copiant les mêmes données et en les supprimant ensuite sur le montage NFS, appelé /nfs_mount/TEST. Cette /nfs_mount/TEST est hébergé/exporté de nfs_server-eth1. Le MTU sur les deux interfaces réseau est 9000, le commutateur entre les supports jumbo prend également en charge. Si je fais rsync -av dir /nfs_mount/TEST/ J'obtiens la vitesse de transfert du réseau X Mbps. Si je 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.
Conclusion: les deux transferts passent par le même sous-réseau, les mêmes câbles, 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 via rsync.
Le client est Ubuntu 10.04, le serveur Ubuntu 9.10.
Comment se fait-il que rsync soit beaucoup plus rapide? Comment faire correspondre NFS à cette vitesse?
Merci
Edit: veuillez noter que j'utilise rsync pour écrire sur le partage NFS ou SSH dans le serveur NFS et y écrire localement. Les deux fois je fais rsync -av, en commençant par le répertoire de destination clair. Demain, je vais essayer avec copie simple.
Edit2 (informations supplémentaires): la taille du fichier varie de 1 Ko à 15 Mo. Les fichiers sont déjà compressés, j'ai essayé de les compresser davantage sans succès. J'ai fait tar.gz fichier de ce dir. Voici le schéma:
rsync -av dir /nfs_mount/TEST/= transfert le plus lent;rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= rsync le plus rapide avec les trames jumbo activées; sans trames jumbo est un peu plus lent, mais toujours beaucoup plus rapide que celui directement vers NFS;rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/= à peu près le même que son équivalent non tar.gz;
Tests avec cp et scp:
cp -r dir /nfs_mount/TEST/= légèrement plus rapide quersync -av dir /nfs_mount/TEST/mais toujours beaucoup plus lent quersync -av dir nfs_server-eth1:/nfs_mount/TEST/.scp -r dir /nfs_mount/TEST/= globalement le plus rapide, dépasse légèrementrsync -av dir nfs_server-eth1:/nfs_mount/TEST/;scp -r dir.tar.gz /nfs_mount/TEST/= à peu près 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 un gros fichier tar.gz ou plusieurs petits. Les images Jumbo activées ou désactivées ne font également pratiquement aucune différence. cp et scp sont plus rapides que leurs _ rsync -av équivalents. L'écriture directement sur le partage NFS exporté est beaucoup plus lente (au moins 2 fois) que l'écriture dans le même répertoire via SSH, quelle que soit la méthode utilisée.
Les différences entre cp et rsync ne sont pas pertinentes dans ce cas. J'ai décidé d'essayer cp et scp juste pour voir s'ils montrent le même modèle et ils le font - différence 2X.
Comme j'utilise rsync ou cp dans les deux cas, je ne comprends pas ce qui empêche NFS d'atteindre la vitesse de transfert des mêmes commandes via SSH.
Comment se fait-il que l'écriture sur le partage NFS soit 2 fois plus lente que l'écriture au même endroit via SSH?
Edit3 (options du serveur NFS/etc/exports): rw,no_root_squash,no_subtree_check,sync. Le/proc/mounts du client affiche: 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 la synchronisation et voyez si cela comble l'écart de vitesse. Lorsque vous rsync sur ssh, le processus rsync distant écrit de manière asynchrone (rapidement). Mais 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 jusqu'à ce qu'il atteigne le disque (ou plus probablement le cache du contrôleur) avant d'envoyer une confirmation au client NFS que l'écriture a réussi.
Si 'async' résout votre problème, sachez que si quelque chose arrive au milieu de l'écriture du serveur NFS, vous pourriez très bien vous retrouver avec des données incohérentes sur le disque. Tant que ce montage NFS n'est pas le stockage principal de ces données (ou de toute autre), tout ira probablement bien. Bien sûr, vous seriez dans le même bateau si vous débranchiez la prise sur le serveur nfs pendant/après l'exécution de rsync-over-ssh (par exemple, rsync retourne avoir "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 cela ne soit pas un problème avec votre test (rsynchronisation de nouvelles données), sachez que rsync sur ssh peut faire un processeur important et IO demandes sur le serveur distant avant qu'un seul octet ne soit transféré pendant le calcul des sommes de contrôle et générer la liste des fichiers à mettre à jour.
NFS est un protocole de partage, tandis que Rsync est optimisé pour les transferts de fichiers; il y a beaucoup d'optimisations qui peuvent être faites lorsque vous savez a priori que votre objectif est de copier les fichiers aussi rapidement que possible au lieu de fournir un accès partagé à leur.
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 en quelque sorte. 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 tas de petits fichiers (par exemple, des e-mails dans des fichiers individuels), l'efficacité NFS peut être en train de s'effondrer en raison de ne pas utiliser le MTU complet (c'est peut-être moins probable avec TCP sur UDP cependant)) .
Alternativement, 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 une accélération simplement par 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 évite de transférer les fichiers.
(*) Dans ce cas, par `` vitesse '', je fais référence à la vitesse à laquelle le CPU peut compresser les données par rapport à la vitesse à laquelle le réseau peut transmettre des données, par ex. il faut 5 secondes pour envoyer 5 Mo sur le câble, mais le processeur peut compresser ces 5 Mo en 1 Mo en 1 seconde. Dans ce cas, votre temps de transmission des données compressées serait légèrement supérieur à 1 seconde, tandis que les données non compressées sont de 5 secondes.
si votre objectif est de simplement copier tous les fichiers d'un endroit à un autre, tar/netcat sera l'option la plus rapide. si vous savez que vous avez beaucoup d'espace dans vos fichiers (zéros), utilisez l'option -i.
SOURCE: tar cvif -/chemin/vers/source | nc DESTINATION PORTNUM DESTINATION: cd/chemin/vers/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 .. parallèle xz, il offre une excellente compression et je peux régler le nombre de processeurs que j'ai sur la bande passante du réseau. si j'ai une bande passante plus lente, j'utiliserai une compression plus élevée, donc j'attends plus de CPU que de réseau .. si j'ai un réseau rapide, j'utiliserai une compression très faible:
SOURCE: tar cvif -/chemin/vers/source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ignorer 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 ajustez le niveau de compression et les cœurs à droite, en fonction de votre ensemble de données, vous devriez être en mesure de garder le réseau proche de saturé et de faire une compression suffisante, votre goulot d'étranglement devient le disque (généralement le côté écriture si les systèmes de lecture et d'écriture sont le même).
quant à rsync, je pense qu'il ignore les zéros de la même manière que tar avec cette option, il transmet donc moins de données que NFS. NFS ne peut pas faire d'hypothèses sur les données et doit donc transmettre chaque octet avec la surcharge du protocole NFS. rsync a des frais généraux ..
netcat n'en a pratiquement aucun. Il enverra des paquets complets TCP 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 le temps, vous ne pouvez pas être sélectif comme avec rsync donc il ne convient pas pour les sauvegardes incrémentielles ou ce genre de chose, mais c'est bon pour copier des données ou archiver.
J'utilise également -e "ssh Ciphers = arcfour" pour augmenter le débit.
Avez-vous une configuration de verrouillage de fichiers sur le partage nfs? Vous pourriez obtenir beaucoup plus de performances si cela était désactivé.