Tempo para zipar arquivos muito grandes (100G)

21

Eu tenho que comprimir vários arquivos muito grandes (80-ish GB), e estou surpreso com a (falta de) velocidade que meu sistema está exibindo. Eu tenho cerca de 500 MB / min velocidade de conversão; usando top , pareço estar usando uma única CPU em aproximadamente 100%.

Tenho certeza que não é (apenas) a velocidade de acesso ao disco, já que criar um arquivo tar (é assim que o arquivo 80G foi criado) levou apenas alguns minutos (talvez 5 ou 10), mas depois de mais de 2 horas meu comando gzip simples ainda não está pronto.

Em resumo:

tar -cvf myStuff.tar myDir/*

Levou 5 minutos para criar um arquivo com 87 G

gzip myStuff.tar

Demorou duas horas e 10 minutos, criando um arquivo zip de 55G.

Minha pergunta: isso é normal? Existem algumas opções em gzip para acelerar as coisas? Seria mais rápido concatenar os comandos e usar tar -cvfz ? Eu vi referência a pigz - Implementação Paralela do GZip - mas infelizmente não consigo instalar software na máquina que estou usando, então isso não é uma opção para mim. Veja, por exemplo, esta pergunta anterior .

Estou pretendendo experimentar algumas dessas opções e tempo-los - mas é bastante provável que eu não vou bater "a combinação mágica" de opções. Espero que alguém neste site saiba o truque certo para acelerar as coisas.

Quando eu tiver os resultados de outros testes disponíveis, atualizarei esta questão - mas se alguém tiver um truque particularmente bom disponível, eu realmente aprecio isso. Talvez o gzip leve mais tempo de processamento do que eu percebi ...

UPDATE

Como prometido, tentei os truques sugeridos abaixo: altere a quantidade de compactação e altere o destino do arquivo. Eu tenho os seguintes resultados para um tar que foi de cerca de 4,1 GB:

flag    user      system   size    sameDisk
-1     189.77s    13.64s  2.786G     +7.2s 
-2     197.20s    12.88s  2.776G     +3.4s
-3     207.03s    10.49s  2.739G     +1.2s
-4     223.28s    13.73s  2.735G     +0.9s
-5     237.79s     9.28s  2.704G     -0.4s
-6     271.69s    14.56s  2.700G     +1.4s
-7     307.70s    10.97s  2.699G     +0.9s
-8     528.66s    10.51s  2.698G     -6.3s
-9     722.61s    12.24s  2.698G     -4.0s

Então, sim, alterar o sinalizador do -6 padrão para o -1 mais rápido me dá uma aceleração de 30%, com (para meus dados) praticamente nenhuma alteração no tamanho do arquivo zip. Se eu estou usando o mesmo disco ou outro, não faz diferença alguma (eu teria que executar isso várias vezes para obter qualquer significância estatística).

Se alguém estiver interessado, eu gero esses benchmarks de tempo usando os dois scripts a seguir:

#!/bin/bash
# compare compression speeds with different options
sameDisk='./'
otherDisk='/tmp/'
sourceDir='/dirToCompress'
logFile='./timerOutput'
rm $logFile

for i in {1..9}
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $sameDisk $logFile
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $otherDisk $logFile
done

E o segundo script ( compressWith ):

#!/bin/bash
# use: compressWith sourceDir compressionFlag destinationDisk logFile
echo "compressing $1 to $3 with setting $2" >> $4
tar -c $1 | gzip -$2 > $3test-$2.tar.gz

Três coisas a notar:

  1. Usando /usr/bin/time em vez de time , pois o comando interno de bash tem muito menos opções que o comando GNU
  2. Eu não me incomodei em usar a opção --format , embora isso tornasse o arquivo de log mais fácil de ler
  3. Eu usei um script-em-um-script, pois time parecia operar apenas no primeiro comando em uma sequência canalizada (então fiz com que parecesse um único comando ...).

Com tudo isso aprendido, minhas conclusões são

  1. Acelerar as coisas com o sinal -1 (resposta aceita)
  2. Muito mais tempo gasta compactando os dados do que lendo do disco
  3. Invista em softwares de compactação mais rápidos ( pigz parece ser uma boa escolha).

Obrigado a todos que me ajudaram a aprender tudo isso!

    
por Floris 03.05.2013 / 19:20

4 respostas

22

Você pode alterar a velocidade do gzip usando --fast --best ou -# , em que # é um número entre 1 e 9 (1 é mais rápido, mas menos compactado, 9 é mais lento, mas mais compactado). Por padrão gzip funciona no nível 6.

    
por 03.05.2013 / 19:45
21

O motivo pelo qual o tar leva tão pouco tempo comparado ao gzip é que há muito pouca sobrecarga computacional para copiar seus arquivos em um único arquivo (que é o que ele faz). gzip no outro lado, está realmente usando algoritmos de compressão para reduzir o arquivo tar.

O problema é que o gzip é restrito (como você descobriu) a um único thread.

Digite pigz , que pode usar vários segmentos para realizar a compactação. Um exemplo de como usar isso seria:

tar -c --use-compress-program=pigz -f tar.file dir_to_zip

Existe um resumo sucinto da opção --use-compress-program sobre um site-irmão .

    
por 29.02.2016 / 12:41
4

I seem to be using a single CPU at approximately 100%.

Isso implica que não há um problema de desempenho de I / O, mas que a compactação está usando apenas um thread (que será o caso do gzip).

Se você conseguir o acesso / acordo necessário para instalar outras ferramentas, o 7zip também suporta múltiplos threads para tirar proveito de CPUs multi-core, embora eu não tenha certeza se isso se estende ao formato gzip, bem como próprio.

Se você está preso a usar apenas gzip por enquanto e tem vários arquivos para compactar, você pode tentar compactá-los individualmente - dessa forma você usará mais dessa CPU multi-core executando mais de um processo em paralelo . Tenha cuidado para não exagerar, porque assim que você chegar perto da capacidade do seu subsistema de E / S, o desempenho cairá abruptamente (para menos do que se você estivesse usando um processo / thread), pois a latência dos movimentos da cabeça se torna significativa. gargalo.

    
por 09.05.2013 / 16:23
1

Também é possível explorar o número de processos disponíveis no pigz, o que geralmente é um desempenho mais rápido, conforme mostrado no comando a seguir

tar cf - directory to archive | pigz -0 -p largenumber > mydir.tar.gz

Example - tar cf - patha | pigz -0 -p 32 > patha.tar.gz

Isso provavelmente é mais rápido do que os métodos sugeridos no post como -p é o número de processos que podem ser executados. Na minha experiência pessoal, definir um valor muito grande não prejudica o desempenho se o diretório a ser arquivado consistir em um grande número de arquivos pequenos. Além disso, o valor padrão considerado é 8. Para arquivos grandes, minha recomendação seria configurar esse valor como o número total de encadeamentos suportados no sistema.

Exemplo de configuração de um valor de p = 32 no caso de uma máquina de 32 CPUs ajudar.

0 foi criado para a compressão mais rápida de pigz, já que não compacta o arquivo e está focado na velocidade. O valor padrão é 6 para compactação.

    
por 29.10.2018 / 05:37

Tags