Como distribuir a computação de 'tar czf' por mais tempo?

Question

Meus sistemas ficam sob carga pesada quando eu corro

sudo tar czf /media/masi/ntfsDisc/backup_home.tar.gz $HOME/

Os fãs vão para o máximo, etc. Eu gostaria de encontrar um melhor equilíbrio entre o consumo de computação e de energia. Eu não posso monitorar o processo bem o suficiente. Você não pode desacelerar durante o cálculo quando executado assim. Intuição: adicione um pouco de sono lá, mas como. Eu realmente gostaria de ter uma abordagem xargs também, para compará-la a produtos "prontos". Meus topos

• Eu faço top em repouso

  top - 09:34:34 up 19:14,  1 user,  load average: 0.52, 0.42, 0.24
  Tasks: 236 total,   1 running, 235 sleeping,   0 stopped,   0 zombie
  %Cpu(s):  1.5 us,  1.1 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 s
  KiB Mem :  8115460 total,   257036 free,  3006452 used,  4851972 buff/cache
  KiB Swap:  8326140 total,  8321852 free,     4288 used.  4369448 avail Mem 
  

• Eu faço top 1 minuto após o nice tar czf ...

  top - 09:48:49 up 19:28,  1 user,  load average: 1.63, 0.99, 0.62
  Tasks: 244 total,   2 running, 242 sleeping,   0 stopped,   0 zombie
  %Cpu(s):  1.4 us,  0.9 sy, 24.1 ni, 73.2 id,  0.3 wa,  0.0 hi,  0.1 si,  0.0 s
  KiB Mem :  8115460 total,   127644 free,  3237648 used,  4750168 buff/cache
  KiB Swap:  8326140 total,  8321868 free,     4272 used.  4092404 avail Mem 
  
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   
  28831 root      30  10    4640   1600   1316 R  97.7  0.0   1:43.24 gzip      
   9573 root      20   0   21196   2860   1772 S   2.3  0.0  13:16.29 mount.nt+ 
    842 root      20   0  380136  63780  48568 S   1.7  0.8  23:57.16 Xorg      
  

• Eu faço top 10 minutos após o início

  top - 10:00:33 up 19:40,  1 user,  load average: 1.98, 2.13, 1.50
  Tasks: 253 total,   2 running, 251 sleeping,   0 stopped,   0 zombie
  %Cpu(s):  2.6 us,  2.8 sy, 21.4 ni, 73.0 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 s
  KiB Mem :  8115460 total,   130408 free,  4432384 used,  3552668 buff/cache
  KiB Swap:  8326140 total,  8321948 free,     4192 used.  2837616 avail Mem 
  
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   
  28831 root      30  10    4640   1600   1316 R  87.0  0.0  11:49.08 gzip      
   9573 root      20   0   21196   2860   1772 S  13.6  0.0  14:45.84 mount.nt+ 
    842 root      20   0  384936  66304  51092 S   2.0  0.8  24:18.44 Xorg      
  28830 root      30  10   37584   3096   2688 S   1.3  0.0   0:14.50 tar       
   1674
  

Meu PV tar cf - $HOME/ | pv | gzip > media/masi/ntfsDisc/testbackup.tar.gz

• em 1 min, 13 - 22 MB / s; aos 2 min, 14 - 22 MB / s; 3 min, 5 - 7 MB / s; aos 4 min, 5 - 22 MB / s; 5 min, 15 - 17 MB / s; aos 6 min, 8 - 24 MB / s; às 7 min, 16 - 20 MB / s
• aos 19 min, 18-21 MB / se os fãs pouco / firmemente de tal forma que você pode ouvi-los

Sistema: Ubuntu 16.04 64 bit
Hardware: Macbook Air 2013-mid

    

Answer 1

O comando

tar czf /media/masi/ntfsDisc/backup_home.tar.gz $HOME/

é o mesmo que isto:

tar cf - $HOME/ | gzip > /media/masi/ntfsDisc/backup_home.tar.gz

Quando você executou top , ele mostrou que o gzip estava usando cerca de 100% de um thread cpu. O software NTFS FUSE também está usando uma quantidade diferente de zero de CPU, mas essencialmente você está ligado à CPU por causa desse gzip. Sua média de carga é de aproximadamente 2 e, com 2 núcleos de 2 segmentos cada, você não sobrecarrega o sistema.

Mas, se seu objetivo é reduzir o uso máximo da CPU (porque os ventiladores estão funcionando no máximo), uma maneira fácil de fazer isso é diminuir a taxa dos dados que estão sendo alimentados para o gzip.

Você executou o teste

tar cf - $HOME/ | pv | gzip > /media/masi/ntfsDisc/testbackup.tar.gz

e pv indicaram que a taxa de transferência de pico em gzip era de 20MiB / seg. Eu recomendaria cortar isso pela metade dando a opção -L 10m a pv.

tar cf - $HOME/ | pv -L 10m | gzip > /media/masi/ntfsDisc/testbackup.tar.gz

Tente ajustar o limite de taxa para mais ou para menos até obter o uso da CPU que você gosta.

    

Answer 2

Em primeiro lugar, o consumo geral de energia será provavelmente igual ou maior se você desacelerar artificialmente o processo de backup. Simplesmente porque o número total de operações é o mesmo e se o processo leva mais tempo, o cpu consome menos potência de pico, mas por um longo tempo. Por exemplo, se o processo for executado por 10 s na potência máxima de 200W, isso consumirá 10s * 200W = 2000J, se o processo funcionar por 100s a 30W, isso consumirá 100s * 30W = 3000J.

Se você está principalmente após melhorar a capacidade de resposta do seu computador durante o processo, você poderia tentar aumentar a qualidade do processo (bom abaixará a prioridade da cpu, liberando energia da CPU para outros processos, ionice irá reduzir a prioridade do disco, liberando o E / S de disco para outros processos):

sudo nice -n19 ionice -c2 -n7 tar czf /media/masi/ntfsDisc/backup_home.tar.gz $HOME/

Isso reduzirá a prioridade do processo para que ele não diminua a velocidade de outros processos enquanto você estiver trabalhando na máquina. Além disso, ele ainda tentará finalizar o processo o mais rápido possível e fazer com que seus fãs acelerem.

Se você realmente quiser / precisar reduzir o pico de consumo de energia (porque seu sistema superaquece ou os fãs o acordam à noite), você pode tentar uma das seguintes abordagens:

Uma solução mais elaborada seria não compactar tudo de uma vez, mas diretório por diretório (coloque este código em um arquivo chamado backup_home.sh, torne-o executável e execute-o via sudo backup_home.sh ):

#!/bin/bash
OLDIFS=$IFS
IFS='
'
for dir in $(ls -d1 $HOME/*); do
   nice tar rf /media/masi/ntfsDisc/backup_home.tar $HOME/
   sleep 10
done;
gzip /media/masi/ntfsDisc/backup_home.tar
IFS=$OLDIFS

Observe, no entanto, que o consumo geral de energia não será reduzido, ele simplesmente se espalhará por mais tempo (aumentando a possibilidade de um arquivo ser alterado durante o backup. Além disso, isso não distribuirá a carga uniformemente, provavelmente nem todas as pastas tenho o mesmo tamanho.Eu recomendo que você use bom e deixe o resto para o sistema.

Por fim, se você quiser mergulhá-lo, use a escala de frequência da CPU para fazer o underclock manualmente CPU durante a duração do backup

    

Answer 3

Uma abordagem seria usar compactação paralela para usar todos os núcleos do sistema e, portanto, reduzir o tempo de compactação. Não reduzirá a carga do seu sistema, mas será carregado por um curto período de tempo!

Você pode encontrar como fazer isso com este Q / A, por exemplo: using-multi-core-for-targzip-bzip-compression-descompressão

Por exemplo:

tar cf - paths-to-archive | pigz > archive.tar.gz