Por que o tar -c dir | pigz /mnt/nfs/dir.tgz usa rede, então cpu em ciclos ao invés de ambos de uma vez (com um gargalo)

Question

Eu quero transferir um diretório multi-terabyte para um diretório nfs montado de forma mais eficiente através de uma rede de 1 Gbit (provavelmente o fator limitante)

3 opções -

1. tar e comprimir no lugar, copie
2. copie, depois tar e comprima
3. tar | comprimir

Parece óbvio para mim que o número 3 deve ser mais eficiente, pois só estou lendo e escrevendo os dados uma vez. Infelizmente, meu comando (tar -c dir | pigz > /mnt/nfs/dir.tgz) parece ter um pouco de tar por um tempo, depois zip por um tempo, depois tar por um tempo ... e a rede fica inativa por grandes pedaços de tempo, então a cpu está ociosa.

Eu senti falta de alguma opção?

P.S. Minha pergunta parece relacionada a esta questão mas isso não tem resposta e realmente não faz a pergunta precisa sobre a alternância entre a saturação da rede e da CPU.

    

Answer 1

Você pode estar esquecendo o fato de que no UNIX / Linux um processo só pode fazer apenas uma operação de E / S de BLOCKING por vez. Não há operações simultâneas de leitura ou gravação contidas nas funções tar ou compress. Também não há processamento de dados em nenhum desses dois processos durante suas chamadas de E / S.

Existem filtros de buffer que tentam diminuir esse efeito usando memória compartilhada e dois processos: um para ler e outro para escrever.

Nesse modelo, você precisará reanalisar suas opções para determinar o gargalo e a ordem operacional do sistema real.