dd comando piped sobre gzip e ssh mais rápido e mais rápido como dd progride

3

Estou executando o seguinte comando para copiar um LVM de um host para outro:

dd if=/dev/vg_1/lv1 conv=noerror,sync bs=4M | gzip | ssh user@ip 'gzip -d | dd of=/dev/vg_2/lv1 bs=4M'

Para começar, eu estava obtendo uma velocidade de cerca de 11 MB / s há cerca de uma hora. Com o passar do tempo, a taxa de transferência cresceu para cerca de 34,4 MB / se continua crescendo a uma taxa constante.

Estou muito curioso para saber o porquê.

Meu melhor palpite é que o LVM que estou copiando é muito grande, mas apenas uma pequena parte dele é, na verdade, dados. Como resultado, talvez grandes blocos de dados sejam preenchidos com 0. Isso tornaria a compactação gzip muito mais eficiente?

    
por user2284355 21.04.2014 / 22:31

1 resposta

4

Seu comando pode ser simplificado, deixando de fora os dois comandos gzip . Se a compactação for útil no seu caso, é muito mais simples compactar os dados em trânsito, dando um argumento -C ao comando ssh , também é menos propenso a erros, já que você não usa acidentalmente o gzip em uma extremidade e não o outro.

Para responder à sua pergunta original e para dizer se a compactação está melhorando a taxa de transferência ou não, primeiro você precisa descobrir onde está o gargalo.

Existem cinco candidatos para o gargalo:

  1. E / S na origem
  2. CPU na origem
  3. Taxa de transferência de rede
  4. CPU no destino
  5. E / S no alvo

Olhando a parte superior de cada computador, você deve saber se há um processo relacionado aos gastos de transferência próximos a 100% do tempo de CPU. Se for esse o caso, é um sinal claro de que a CPU nesse computador é o gargalo.

Se o OTOH vir o comando dd em uma das extremidades passando muito tempo em D state (significando sleep não interrompível), é uma indicação de que aE / O nesse computador é o gargalo.

Para descobrir se a rede é o gargalo, consulte netstat output. Se a rede é o gargalo, você deve ver uma grande fila de envio na origem e a fila de recebimento vazia no destino.

Se a fila de envio e a fila de recebimento forem grandes, isso indica que o gargalo está no destino. Se ambos estiverem vazios, isso indica que o gargalo está na origem.

Se uma cópia sem compactação acabar com um afunilamento na conexão de rede, a compactação provavelmente melhorará o desempenho. Se o gargalo estava em outro lugar, é improvável que a compactação ajude. Se o tempo de CPU passar a criptografar e descriptografar dados fosse o gargalo em primeiro lugar, a compactação pode afetar o desempenho, a menos que os dados sejam muito redundantes e obtenham uma alta taxa de compactação.

A taxa de transferência pode mudar ao longo do tempo por vários motivos. Isso pode fazer com que o local do gargalo mude conforme você está tentando localizá-lo. É provável que a compactação cause muito mais variações no rendimento devido às variações na taxa de compactação, que é a explicação mais provável para o que você está vendo.

Mas o rendimento pode variar por muitos outros motivos, incluindo:

  • Fragmentação na mídia subjacente
  • Setores defeituosos na mídia reduzindo as transferências de dados
  • Propriedades físicas da mídia causando variação na taxa de transferência dependendo da localização na mídia.
  • Carregar no computador causado por outros processos não relacionados
  • Variações na capacidade de rede disponível
por 22.04.2014 / 00:56

Tags