Usando uma ótima prioridade de agendamento com script cron tar / gzip

5

Eu faço grandes backups que colocam grandes esforços no meu servidor quando uso tar/gzip . Eu tenho a configuração da tarefa como um cronjob que acessa meu script que lida com o backup. Eu sei que nice pode ser capaz de ajudar nesta situação, mas estou um pouco incerto sobre a maneira correta de usá-lo.

Eu tenho os seguintes comandos no meu script:

tar -cf 
gzip -9 

Eu adicionaria o comando nice na frente dele assim para reduzir a prioridade?:

nice -n 13 tar -cf 
nice -n 13 gzip -9

Há alguma limitação em usar essa abordagem? obrigado.

    
por Joe Habadas 15.02.2015 / 23:06

3 respostas

8

Há advertências para prestar atenção. Uma vez que a questão não especifica um sistema operacional exato (mas implica que há algum sistema operacional semelhante ao Unix), a lista de advertências dependerá do sistema operacional e da versão específicos. O mais importante a ter em mente é:

nice destina-se a afetar quanto tempo de CPU é dado a um processo, mas não quanto RAM ou capacidade de E / S. Assim, em vez do efeito pretendido, outros resultados possíveis incluem:

  • O backup leva mais tempo para ser concluído devido ao menor tempo de CPU. Mas usará tanto RAM quanto costumava e agora usará essa RAM por mais tempo. O sistema é retardado devido a ter menos RAM para outros propósitos, e essa lentidão vai durar mais tempo do que costumava.
  • O uso de nice não tem nenhum efeito, porque o processo de backup foi iniciado com E / S e o agendamento de E / S não é afetado por nice . Se o sistema operacional for uma versão recente do Linux, o agendamento de E / S pode ou não ser afetado por nice dependendo de qual ionice está sendo usada.

Além disso, mesmo o efeito exato no agendamento da CPU depende muito do sistema operacional e das configurações específicas. Alguns kernels possuem configurações que permitem que um processo seja executado em uma prioridade maior ou menor do que aquelas alcançáveis usando o comando nice .

Uma ressalva que eu tenho em mim parece ser específica para o Ubuntu 14.04. Na configuração padrão, ele agrupa processos para fins de agendamento. Cada grupo recebe uma parte justa do tempo da CPU. nice afeta apenas como o tempo de CPU é alocado para processos dentro de um grupo, mas não quanto é alocado para cada grupo. Para mim, isso prejudicou completamente o uso de nice , porque um processo de baixa prioridade ainda poderia tirar o tempo de CPU dos processos em diferentes grupos.

    
por 15.02.2015 / 23:20
5

Eu adotaria uma abordagem diferente ...

Não, eu não iria mexer com nice para isso. E gzip não é tão bom assim. Além disso, você está usando gzip -9 , que oferece as maiores taxas de compactação às custas da CPU. Você realmente precisa desse nível de compressão sobre o padrão (nível 6)?

Seu sistema fica sobrecarregado se você não usa o nível 9 do gzip?

Quais são as especificações do seu servidor? Quantos e que tipos de CPUs você tem? cat /proc/cpuinfo

Se você tem várias CPUs, você consideraria usar pigz ? É multithreaded, um pouco mais eficiente e pode aproveitar os recursos do seu sistema muito melhor.

Alguns testes com um arquivo de 1,8 GB:

Padrão gzip (nível de compressão -6)

Original file size: 1.8G    CHL0001.TXT 
Compression time: 0m18.335s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m6.300s

gzip -9 (maior compactação)

Original file size: 1.8G    CHL0001.TXT
Compression time: 1m29.432s
Compressed file size: 75M   CHL0001.TXT.gz
Decompression time: 0m6.325s

pigz (nível de compressão -6)

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m1.878s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m2.506s

pigz -9 (compactação mais alta, multithread)

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m5.611s
Compressed file size: 76M   CHL0001.TXT.gz
Decompression time: 0m2.489s

Conclusão: o bit extra de compactação vale o tempo consideravelmente maior gasto na compactação dos dados?

    
por 15.02.2015 / 23:49
2

Eu percebo que isso está se desviando da pergunta original, mas ela está se mantendo no tema da eficiência (você menciona "grandes tensões no meu servidor") ...

Estou inferindo (ou adivinhando!) a partir do que você postou que está criando um tar contendo um conjunto de arquivos e, em seguida, gzip -ing o resultado. Você pode economizar um monte de E / S de disco (e espaço temporário) canalizando um diretamente para o outro:

tar cf - /path/to/stuff | gzip > archive.tar.gz

Você pode achar que isso faz uma diferença significativa no tempo total decorrido.

    
por 24.02.2015 / 14:53

Tags