gzip * .txt vs gzip test.txt & gzip test2.txt &

Question

Estou procurando acelerar o processo do gzip. (servidor é AIX 7.1)

Mais especificamente, a implementação atual é com gzip *.txt e leva até 1h para ser concluída. (as extrações de arquivos são muito grandes e temos um total de 10 arquivos)

Pergunta: Será mais eficiente executar

pids=""
gzip file1.txt &
pids+=" $!"
gzip file2.txt &
pids+=" $!"
wait $pids

do que

gzip *.txt 

O comportamento gzip *txt é o mesmo em termos de paralelismo, consumo de cpu etc, já que o gzip em segundo plano (&) ou a outra opção será mais eficiente?

    

Answer 1

Não reinvente a roda. Você pode usar pigz , uma implementação paralela de gzip , que deve estar em seus repositórios de distribuição. Se não for, você pode obtê-lo em aqui .

Depois de instalar o pigz , use-o como você faria com gzip :

pigz *txt

Eu testei isso em 5 arquivos de 30M criados usando for i in {1..5}; do head -c 50M /dev/urandom > file"$i".txt; done :

## Non-parallel gzip
$ time gzip *txt
real    0m8.853s
user    0m8.607s
sys     0m0.243s

## Shell parallelization (same idea as yours, just simplified)
$ time ( for i in *txt; do gzip $i & done; wait)

real    0m2.214s
user    0m10.230s
sys     0m0.250s

## pigz
$ time pigz *txt

real    0m1.689s
user    0m11.580s
sys     0m0.317s

    

Answer 2

O único caminho real é o tempo. Eu esperaria que gzip *.txt os fizesse um de cada vez, pois são arquivos separados.

Executá-los em paralelo (usando gzip file1.txt etc.) pode ser mais rápido, mas dependerá de quanta memória você tem, quantos núcleos de CPU, etc. O fator mais importante é que você obterá contenção pelo disco enquanto estiver fazendo isso, e isso pode retardar muito as coisas (a menos que seja um SSD e, até certo ponto, até certo ponto). Ambos usarão uma quantidade similar de tempo de CPU no total.

Eu geralmente uso gzip *.txt ou similar.