Por que pipiar 'dd' através do gzip é muito mais rápido que uma cópia direta?

Question

Eu queria fazer o backup de um caminho de um computador na minha rede para outro computador na mesma rede em uma linha de 100 Mbit / s. Por isso eu fiz

dd if=/local/path of=/remote/path/in/local/network/backup.img

que me deu uma velocidade de transferência de rede muito baixa de algo entre 50 e 100 kB / s, o que teria demorado para sempre. Então eu parei e decidi tentar fazer isso rapidamente para torná-lo muito menor, para que a quantidade de transferência fosse menor. Então eu fiz

dd if=/local/path | gzip > /remote/path/in/local/network/backup.img.gz

Mas agora obtenho algo como 1 MB / s de velocidade de transferência de rede, portanto, um fator de 10 a 20 mais rápido. Depois de perceber isso, eu testei isso em vários caminhos e arquivos, e sempre foi o mesmo.

Por que o piping dd através de gzip também aumenta as taxas de transferência por um fator grande, em vez de apenas reduzir o bytelength do fluxo por um fator grande? Eu esperava até mesmo um pequeno diminuir em taxas de transferência, devido ao maior consumo de CPU durante a compactação, mas agora eu recebo um duplo mais. Não que eu não esteja feliz, mas estou apenas imaginando. ;)

    

Answer 1

dd por padrão usa um tamanho de bloco muito pequeno - 512 bytes (!!). Ou seja, muitas pequenas leituras e gravações. Parece que dd , usado ingenuamente em seu primeiro exemplo, estava gerando um grande número de pacotes de rede com uma carga útil muito pequena, reduzindo assim a taxa de transferência.

Por outro lado, gzip é inteligente o suficiente para fazer I / O com buffers maiores. Ou seja, um número menor de gravações grandes na rede.

Você pode tentar dd novamente com um parâmetro bs= maior e ver se funciona melhor desta vez?

    

Answer 2

Bit atrasado para isso, mas posso adicionar ...

Em uma entrevista, uma vez me perguntaram qual seria o método mais rápido possível para clonar dados bit-a-bit e de resposta grosseira com o uso de dd ou dc3dd ( DoD financiado ). O entrevistador confirmou que a tubulação dd to dd é mais eficiente, pois isso simplesmente permite leitura / gravação simultânea ou em termos de programador stdin/stdout , dobrando assim as velocidades de gravação e o tempo de transferência de meia. / p>

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

    

Answer 3

O Cong está correto. Você está transmitindo os blocos do disco descompactado para um host remoto. Sua interface de rede, rede e seu servidor remoto são a limitação. Primeiro você precisa melhorar o desempenho do DD. A especificação de um parâmetro bs = que se alinha à memória do buffer de discos obterá o máximo desempenho do disco. Diga bs = 32M, por exemplo. Em seguida, isso preencherá o buffer do gzip no strait de taxa de linha sata ou sas do buffer de unidades. O disco será mais inclinado a transferência sequencial, dando melhor através de put. O Gzip compactará os dados no fluxo e os enviará para o seu local. Se você estiver usando o NFS, isso permitirá que a transmissão do nfs seja mínima. Se você estiver usando o SSH, então você encurta o encapsulamento SSH e a sobrecarga de criptografia. Se você usa o netcat, então você não tem nenhuma criptografia na cabeça.

    

Answer 4

Eu assumo aqui que a "velocidade de transferência" a qual você está se referindo está sendo reportada por dd . Isso realmente faz sentido, porque dd está realmente transferindo 10x a quantidade de dados por segundo ! No entanto, dd não está sendo transferido pela rede - esse trabalho está sendo manipulado pelo processo gzip .

Algum contexto: gzip consumirá dados de seu canal de entrada tão rápido quanto puder limpar seu buffer interno. A velocidade em que o buffer gzip é esvaziado depende de alguns fatores:

• A largura de banda de gravação de E / S (que é afunilada pela rede e permaneceu constante)
• A largura de banda de leitura de E / S (que será muito superior a 1 MB / s de leitura de um disco local em uma máquina moderna, portanto, não é um provável gargalo)
• Sua taxa de compactação (que eu assumirei com seu aumento de 10x em torno de 10%, indicando que você está compactando algum tipo de texto altamente repetitivo como um arquivo de log ou algum XML)

Portanto, nesse caso, a rede pode manipular 100kB / s e gzip está compactando os dados em torno de 10: 1 (e não está sendo afunilada pela CPU). Isso significa que, embora esteja gerando 100kB / s, gzip pode consumir 1MB / s, e a taxa de consumo é o que dd pode ver.