Pourquoi la tuyauterie 'dd' à travers gzip est-elle tellement plus rapide qu'une copie directe?
Je voulais sauvegarder un chemin d'un ordinateur de mon réseau vers un autre ordinateur du même réseau sur une ligne à 100 Mbit/s. Pour cela j'ai fait
dd if=/local/path of=/remote/path/in/local/network/backup.img
ce qui m'a donné une vitesse de transfert réseau très faible d'environ 50 à 100 ko/s, ce qui aurait pris une éternité. Alors je l'ai arrêté et j'ai décidé d'essayer de le gzipper à la volée pour le rendre beaucoup plus petit afin que le montant à transférer soit inférieur. Alors j'ai fait
dd if=/local/path | gzip > /remote/path/in/local/network/backup.img.gz
Mais maintenant, je reçois quelque chose comme une vitesse de transfert réseau de 1 Mo/s, soit un facteur de 10 à 20 fois plus rapide. Après avoir remarqué cela, je l'ai testé sur plusieurs chemins et fichiers, et c'était toujours le même.
Pourquoi la tuyauterie dd à gzip augmente-t-elle également les taux de transfert d'un facteur important au lieu de simplement réduire la longueur de sous-flux du flux? Je m'attendais même à une légère diminution des taux de transfert, en raison de la consommation plus élevée de ressources processeur lors de la compression, mais je reçois maintenant un double plus. Non pas que je ne sois pas heureux, mais je me pose une question. ;)
dd utilise par défaut une très petite taille de bloc - 512 octets (!!). C'est-à-dire beaucoup de petites lectures et écritures. Il semble que dd, utilisé naïvement dans votre premier exemple, génère un grand nombre de paquets réseau avec une charge utile très réduite, ce qui réduit le débit.
Par contre, gzip est suffisamment intelligent pour effectuer des E/S avec des tampons plus importants. C'est-à-dire qu'un plus petit nombre de grosses écritures sur le réseau.
Pouvez-vous essayer à nouveau dd avec un paramètre bs= plus grand et voir si cela fonctionne mieux cette fois-ci?
Peu en retard à cela, mais pourrais-je ajouter ...
Lors d'une interview, on m'a demandé une fois quelle serait la méthode la plus rapide possible pour cloner des données bit à bit} et grossière a répondu par l'utilisation de dd ou dc3dd ( DoD financé ). L’intervieweur a confirmé que la lecture des variables dd à dd est plus efficace, car elle permet tout simplement lecture/écriture simultanées ou en termes de programmation stdin/stdout, doublant ainsi ultimement les vitesses d’écriture et le temps de transfert moitié.
dc3dd verb=on if=/media/backup.img | dc3dd of=/dev/sdb
Cong est correct. Vous diffusez les blocs hors du disque non compressé à un hôte distant. Votre interface réseau, le réseau et votre serveur distant sont la limitation. Vous devez d'abord obtenir des performances de DD vers le haut. Spécifier un paramètre bs = qui s'aligne sur la mémoire tampon des disques optimisera les performances du disque. Dites bs = 32M par exemple. Ceci remplira alors le tampon de gzip au niveau de sata ou de sas à partir du tampon des lecteurs. Le disque sera plus enclin à un transfert séquentiel donnant une meilleure throughput. Gzip compresse les données dans le flux et l'envoyer à votre emplacement. Si vous utilisez NFS, cela permettra à la transmission nfs d’être minime. Si vous utilisez SSH, vous encresz la surcharge d'encapsulation et de cryptage SSH. Si vous utilisez netcat alors vous n'avez pas le chiffrement sur la tête.
Je suppose ici que la "vitesse de transfert" à laquelle vous faites référence est rapportée par dd. Cela a du sens, cardd transfère 10 fois la quantité de données par seconde ! Cependant, dd ne transfère pas sur le réseau - ce travail est traité par le processus gzip.
Certains contextes: gzip consommera les données de son canal d’entrée aussi vite que possible pour effacer son tampon interne. La vitesse à laquelle le tampon gzip est vide dépend de plusieurs facteurs:
- La bande passante d’écriture des E/S (goulet d’étranglement par le réseau et restée constante)
- La bande passante de lecture des E/S (qui sera bien supérieure à 1 Mo/s en lecture à partir d'un disque local sur une machine moderne, ne constitue donc pas un goulot d'étranglement)
- Son taux de compression (ce que je suppose, d'après votre accélération 10x, autour de 10%, ce qui indique que vous compressez un texte très répétitif tel qu'un fichier journal ou un fichier XML)
Donc, dans ce cas, le réseau peut gérer 100 ko/s et gzip compresse les données autour de 10: 1 (et ne fait pas l'objet de goulots d'étranglement de la part du processeur). Cela signifie que, pendant la sortie de 100 Ko/s, gzip peut consommer 1Mo/s, et le taux de consommation correspond à ce que dd peut voir.