Question Pourquoi la diffusion de 'dd' via gzip est-elle tellement plus rapide qu’une copie directe?


Je voulais sauvegarder un chemin depuis 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 très faible vitesse de transfert réseau 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 faire voler à la volée pour le rendre beaucoup plus petit afin que le montant à transférer soit moins élevé. Donc 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 10 à 20 plus rapide. Après avoir remarqué cela, j'ai testé cela sur plusieurs chemins et fichiers, et c'était toujours la même chose.

Pourquoi la tuyauterie dd par gzip également augmenter les taux de transfert par un facteur important au lieu de réduire uniquement la longueur du flux d'un facteur important? Je m'attendais même à une légère diminution des taux de transfert à la place, en raison de la consommation plus élevée du processeur lors de la compression, mais je reçois maintenant un double plus. Non pas que je ne sois pas content, mais je me demande seulement. ;)


76
2018-05-29 08:35


origine


512 octets étaient la taille de bloc standard pour le stockage de fichiers au début d'Unix. Comme tout est un fichier sous Unix / Linux, il est devenu la valeur par défaut pour à peu près tout. Les nouvelles versions de la plupart des utilitaires ont augmenté ce nombre, mais pas le dd. - DocSalvager
La réponse simple est que dd est en train de sortir à 1 Mo / s ... directement dans l'attente gzip tuyau. Cela a très peu à voir avec la taille des blocs. - Tullo_x86


Réponses:


dd utilise par défaut une très petite taille de bloc - 512 octets (!!). C'est-à-dire beaucoup de petites lectures et écritures. Il paraît que dd, utilisé naïvement dans votre premier exemple, générait un grand nombre de paquets réseau avec une très faible charge utile, réduisant ainsi le débit.

D'autre part, gzip est assez intelligent pour faire des E / S avec des tampons plus grands. C'est-à-dire un plus petit nombre de grandes écritures sur le réseau.

Peux-tu essayer dd encore avec un plus grand bs= paramètre et voir si cela fonctionne mieux cette fois?


97
2018-05-29 09:25



Merci, a essayé la copie directe sans pour autant  gzip et une taille de bloc de bs=10M -> transfert réseau rapide d'environ 3 ou 4 Mo / s. Taille de bloc supérieure + gzip n'a rien changé par rapport aux petites tailles de blocs + gzip. - Foo Bar
Si vous voulez voir quelle taille de bloc élevée essayez un autre dd après le gzip. - Joshua
Est-ce que gzip fait ses propres tampons de sortie, ou utilise-t-il simplement stdio? - Barmar
@Barmar Si je lis correctement la source, write(3)s vers le tampon.
@CongMa vous pouvez également essayer d'utiliser pigz au lieu de gzip, cela fonctionnera encore plus vite - GioMac


Un peu tard, mais pourrais-je ajouter ...

Dans une interview on m'a une fois demandé Quelle serait la méthode la plus rapide pour cloner des données bit par bit et de grossier a répondu avec l'utilisation de dd ou dc3dd (DoD financé). L’intervieweur a confirmé que la tuyauterie dd à dd est plus efficace, car cela permet simplement lecture / écriture simultanée ou en termes de programmeur stdin/stdout, doublant ainsi ultimement les vitesses d’écriture et la moitié du temps de transfert.

dc3dd verb=on if=/media/backup.img | dc3dd of=/dev/sdb

3
2017-09-07 21:41





Cong est correct. Vous diffusez les blocs hors du disque non compressé vers un hôte distant. Votre interface réseau, votre réseau et votre serveur distant constituent la limitation. Vous devez d'abord améliorer les performances de DD. La spécification d'un paramètre bs = qui s'aligne sur la mémoire tampon des disques sera la plus performante du disque. Disons bs = 32M par exemple. Cela remplira alors le tampon de gzip à sata ou sas line rate strait du tampon de lecteurs. Le disque sera plus enclin à un transfert séquentiel donnant de meilleurs résultats. Gzip compressera les données dans le flux et les enverra à votre emplacement. Si vous utilisez NFS, cela permettra à la transmission nfs d'être minimale. Si vous utilisez SSH, vous obtenez l'encapsulation SSH et la surcharge de cryptage. Si vous utilisez netcat, vous n'avez pas de cryptage sur la tête.


0
2018-06-26 23:31





Je suppose ici que la "vitesse de transfert" à laquelle vous faites référence est rapportée par dd. Cela a du sens, car ddtransfère en réalité 10 fois la quantité de données par seconde! cependant, dd ne transfère pas sur le réseau - ce travail est géré par le gzip processus.

Un contexte: gzip consomme les données de son canal d’entrée aussi rapidement qu’elle peut effacer son tampon interne. La vitesse à laquelle gzipLe tampon vide dépend de quelques facteurs:

  • La bande passante d'écriture des E / S (qui est goulot par le réseau et est restée constante)
  • La bande passante de lecture des E / S (qui va bien au-delà de 1 Mo / s en lecture sur un disque local sur une machine moderne n'est donc pas un goulot d'étranglement probable)
  • Son taux de compression (que je suppose que votre accélération 10x sera d'environ 10%, indiquant que vous compressez une sorte de texte hautement répétitif comme 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 n’est pas gêné par le processeur). Cela signifie que pendant qu’il produit 100 Ko / s, gzip pouvez consommer 1 Mo / s, et le taux de consommation est ce que dd peut voir.


0
2017-10-21 04:57