Sou um usuário regular em uma instalação remota do Debian (não um administrador). Eu executo lá um servidor de rede para fins especiais que é usado extensivamente. O servidor produz logs diários que são bastante grandes e, de vez em quando, preciso empacotá-los em um 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 disse 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, segundo top, fosse de apenas 5%. Então eu tentei:
nice -n19 tar rf 2014-12.tar 2014-12-*.log &
Enviei o comando para segundo plano para poder monitorar o processo do servidor. Observei que o processo do servidor estava lento, mas não muito, então era aceitável. Tudo funcionou por cerca de 5 minutos e, de repente, o servidor travou novamente. Eu matei o processo tar e vi o servidor imediatamente começar a trabalhar.
O servidor está escutando em um soquete TCP onde muitos clientes estão se conectando. Quando o tar está em execução, o servidor continua funcionando, mas depois de algum tempo a chamada select parece parar de atualizar os soquetes legíveis.
Tudo isso é confuso. O servidor parece ser desligado após alguns minutos quando outra coisa está em execução, mas por outro lado ele funciona sem problemas por meses. Parece também, de acordo com top, que meus processos nunca obtêm mais do que 5% do total da CPU, por que isso aconteceria? Como posso compactar os logs sem atrapalhar o processo do meu servidor?
Responder1
Como muru afirmou, nicecontrola apenas o agendamento da CPU. Você mesmo notou que o uso da CPU era de apenas 5% na época. Isso significa que o sistema estava fortemente limitado por IO, o que significa que a leitura/gravação dos discos era o gargalo.
Você pode controlar a prioridade IO dada a um processo por meio do ionicecomando. Você pode colocar um processo em uma das três classes de agendamento:
- inativo - só obterá tempo de disco quando nenhum outro programa precisar do disco
- melhor esforço - basicamente o padrão
- tempo real - esta classe obtém o primeiro acesso ao disco, não importa o que mais esteja acontecendo
Você pode especificar a classe com a -copção 1 = tempo real, 2 = melhor esforço, 3 = inativo.
Com melhor esforço e tempo real, existem também 8 níveis de prioridade diferentes, para ajustar entre processos da mesma classe.
Normalmente executo comandos como tarou rsyncwith ionice -c3, ou seja, a classe mais baixa "idle". Dessa forma, outros processos não ficam sem acesso ao disco.
Observe que o IMHO ionicefunciona melhor com o agendador de E/S CFQ (um parâmetro do kernel).
Responder2
Provavelmente o comportamento que você observa são detalhes de 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 gravar =). Eu sugiro fortemente que, para evitar o problema, obtenha seu arquivo imediatamente. Não faz sentido armazenar 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, pois ele usa muito pouca CPU tanto para compactar quanto para descompactar. Essa abordagem diminuiria o tempo de criação do tar por um 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 observaria que a alcatrão manual diária é uma ideia meio estranha. Eu sugiro que você configure o logrorate normal e o trabalho cron/anacron para que o sistema faça tudo isso para você automaticamente.
A propósito, que tipo de sistema de arquivos você tem? (usar mount|grep $(stat --printf "%m" .))