'nice' não está realmente ajudando no Linux

Question

Eu sou um usuário comum em uma instalação remota do Debian (não um administrador). Eu corro para lá um servidor de rede para fins especiais que é usado muito extensivamente. O servidor produz logs diários que são bastante grandes e, de tempos em tempos, preciso compactá-los em uma tar-ball mensal e, depois de mais algum tempo, compactá-los. Primeiro eu tentei isso:

tar rf 2014-12.tar 2014-12-*.log

10 minutos depois, um cliente ligou e avisou que o servidor havia parado de responder. Na verdade, o processo do servidor foi "posto de lado" e toda a atenção foi dada ao processo tar, embora a carga total da CPU, de acordo com top , fosse de apenas 5%. Então eu tentei:

nice -n19 tar rf 2014-12.tar 2014-12-*.log &

Enviei o comando para o segundo plano para poder monitorar o processo do servidor. Observei que o processo do servidor havia diminuído, mas não muito, por isso era aceitável. Tudo funcionou por talvez 5 minutos e, de repente, o servidor parou novamente. Eu matei o processo tar e vi o servidor imediatamente correndo para o trabalho.

O servidor está escutando em um soquete TCP onde muitos clientes estão se conectando. Quando o tar está sendo executado, o servidor continua a funcionar, mas depois de algum tempo a chamada selecionada parece parar de atualizar os soquetes legíveis.

Tudo isso é confuso. O servidor parece estar cortado após alguns minutos, quando algo está sendo executado, mas, por outro lado, ele é executado sem problemas por meses. Também parece, de acordo com top , que meus processos nunca chegam a mais de 5% do total da CPU, por que isso seria? Como posso empacotar os logs sem perturbar o processo do meu servidor?

    

Answer 1

Como mencionado, nice controla apenas o agendamento de CPU. Você mesmo observou que o uso da CPU era de apenas 5% no momento. Isso significa que o sistema estava strongmente ligado a E / S, ou seja, ler / gravar os discos era o gargalo.

Você pode controlar a prioridade de IO dada a um processo por meio do comando ionice . Você pode colocar um processo em uma das três classes de agendamento:

• ocioso - só terá tempo de disco quando nenhum outro programa precisar do disco
• best-effort - basicamente o padrão
• em tempo real - essa classe obtém o primeiro acesso ao disco, não importando o que esteja acontecendo

Você pode especificar a classe com a opção -c , 1 = tempo real, 2 = melhor esforço, 3 = ocioso.

Com o melhor esforço e em tempo real, há também oito níveis de prioridade diferentes para afinar os processos da mesma classe.

Geralmente, executo comandos como tar ou rsync com ionice -c3 , ou seja, a classe mais baixa "inativa". Dessa forma, outros processos não precisam de acesso ao disco.

Observe que IMHO ionice funciona melhor com o planejador de E / S CFQ (um parâmetro do kernel).

    

Answer 2

Provavelmente, o comportamento observado é detalhes da implementação do seu sistema de arquivos - ele pode coletar muitos dados na memória e gravá-los em massa. A maneira mais simples de resolver isso é diminuir a quantidade de dados que você deseja escrever =). Eu sugeriria strongmente, para evitar o problema, imediatamente atingir seu arquivo. Não há nenhum ponto no armazenamento de tar desarquivado se o disco estiver lento. Para criar um arquivo, basta adicionar a opção -z à sua linha de comando tar: tar rzf 2014-12.tar.gz 2014-12-*.log . É melhor usar o gzip na maioria dos casos, já que ele usa muito pouca CPU tanto na compactação quanto na descompactação. Essa abordagem diminuiria seu tempo de criação de tar por fator de 10 ou 20 e também diminuiria a quantidade de dados a serem gravados pelo sistema de arquivos pelo mesmo fator.

Eu também notaria que o tarring manual diário é uma ideia estranha. Eu sugiro que você configure o trabalho normal logrorate e cron / anacron para que o sistema faça todas essas coisas automaticamente.

Que tipo de sistema de arquivos você tem? (use mount|grep $(stat --printf "%m" .) )