cron vs. sleep - qual é o melhor em termos de utilização eficiente de cpu / memória?

Question

O caso:

Eu preciso executar alguns comandos / script em determinados intervalos de tempo e, para isso, tenho duas opções:

1. configurar um cron -job
2. implemente um loop com sleep no próprio script.

Pergunta:

Qual é a melhor opção do ponto de vista do consumo de recursos? Por quê? O cron é o melhor caminho? O cron usa algum tipo de gatilho ou algo que o torna eficiente sobre o outro? Qual procedimento o cron usa para verificar e iniciar os trabalhos?

    

Answer 1

Use o cron porque é uma prática melhor e mais padrão. Pelo menos se isso é algo que será executado regularmente (não apenas algo que você corrigiu em um minuto). cron é uma maneira mais limpa e mais padronizada. Também é melhor porque ele executa o shell desconectado de um terminal - não há problema com término acidental e dependências em outros processos.

Em relação aos recursos: CPU: Ambos os processos dormem - quando eles dormem, eles não perdem CPU. cron acorda com mais frequência para verificar as coisas, mas faz isso de qualquer maneira (não mais para o seu processo). E isso é carga insignificante, a maioria dos daemons acordam ocasionalmente. Memória: Você provavelmente tem cron em execução, independentemente desse processo, portanto, isso não é uma sobrecarga. No entanto, o cron só iniciará o shell quando o script for chamado, enquanto seu script permanecerá carregado na memória (um processo bash com o ambiente - alguns kilobytes, a menos que você esteja carregando tudo nas variáveis do shell).

Em resumo, para recursos, não importa.

    

Answer 2

Use cron (ou anacron ).

O Cron é projetado para executar coisas em intervalos. Essa é a única coisa que faz, e tem havido muito trabalho no cron por muitos anos para torná-lo o que é hoje.

As chances de você escrever um planejador melhor no seu script são efetivamente nulas. Usando o cron funcionará melhor, evite ter código desnecessário em seu script e mantenha seu código conciso e mais sustentável.

Não reinvente a roda se você não precisa.

    

Answer 3

Já existem algumas boas respostas sobre cron e sleep performance, mas quero adicionar algum tipo de comparação de recursos.

Pro cron :

• executando já em sistemas Unix / Linux
• estável e comprovado
• projetado para processos em segundo plano
• é executado a partir da inicialização do sistema, assim como seu script, uma vez instalado
• entrada mais fácil de ciclos de longo prazo (horas, dias, semanas)
• permite repetições complexas de longo prazo ("todo segundo domingo às 5:35 am.")

Pro sleep :

• mais fácil de manter em um script
• mais fácil para processos de primeiro plano
• permite tempos de sono mais curtos e precisos do que um minuto
• permite ciclos complexos de suspensão / ação ("execute esta parte, depois durma 10 segundos, depois execute a outra parte e durma duas horas")

Answer 4

A principal diferença que você está procurando é que cron não está sendo executado constantemente. Conforme explicado em man cron :

   cron then wakes up every minute, examining all stored crontabs,  check‐
   ing  each  command  to  see  if it should be run in the current minute.
   When executing commands, any output is  mailed  to  the  owner  of  the
   crontab (or to the user named in the MAILTO environment variable in the
   crontab, if such exists).  The children copies of  cron  running  these
   processes  have their name coerced to uppercase, as will be seen in the
   syslog and ps output.

Em outras palavras, cron será iniciado apenas uma vez por minuto e testará se deve ser executado. Sua abordagem do sono, por outro lado, exigiria que seu comando sleep real, seu shell, seu terminal e o loop while (ou qualquer outro) estivessem sendo executados ao mesmo tempo.

Mesmo se eles estivessem lançando o mesmo número de processos, cron seria melhor. Está escrito precisamente para isso por pessoas que tendem a ser muito boas em seu trabalho. É obrigado a fazer um trabalho melhor do que um simples loop de shell.

    

Answer 5

Does cron use some kind of triggers or something making it efficient over the other?

Eu dei uma olhada em cat /proc/'pidof crond'/stack . Depois de imprimi-lo por algumas vezes consecutivas, vejo que crond apenas dorme em hrtimer_nanosleep.

>cat /proc/'pidof crond'/stack
[<ffffffff810a0614>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a073e>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

O utilitário

sleep usa a mesma chamada de sistema.

>sleep 100 &
[1] 12761
>cat /proc/12761/stack
[<ffffffff810a0614>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a073e>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

Eu assumo que ambos os utilitários ( crond & sleep ) devem ter baixa utilização da CPU e se você precisar imitar cron você definitivamente pode usar sleep .

Atualizar. É melhor observar a atividade de crond com

strace -p 'pidof crond'

    

Answer 6

A diferença é que, à medida que você adiciona mais scripts que precisam dormir, acabará com mais processos aguardando, em vez de um único processo (cron) que ativa e executa quaisquer scripts programados que fecham até a próxima execução . O Cron permite um processo que é especializado para executar outros scripts a tempo, e o cron permite agendar relativamente livremente quando algo deve ser executado, dias da semana ou mês, horários específicos, ou apenas a cada 5 minutos etc.

* Só de ver isso novamente me fez pensar em outra vantagem do cron. Todos os scripts que são executados periodicamente estão em um único lugar e é fácil verificar a partir de quando e com que frequência eles serão executados. Caso contrário, você deve verificar os scripts individuais.

    

Answer 7

Já existem respostas boas e mais informadas, mas eu só queria ressaltar que, com sleep , você tem a capacidade de congelar o processo por um período de tempo variável, como uma função de outras variáveis.

Se eu estiver escrevendo script para verificar a porcentagem de bateria restante e notify-send se estiver abaixo do nível crítico predefinido, posso fazer o script sleep pelo tempo que é uma função da bateria atual nível em porcentagem em vez de verificar a bateria a cada um ou dois minutos com a ajuda do cron mesmo quando eu sei que foi de 80% quando verificado pela última vez.

Battery_notify.sh

#!/bin/bash
CRIT=15
while true; do
    # current battery level
    BAT_LEVEL='acpi -b |grep -Eo "[0-9]+%"|grep -Eo "[0-9]+"'
    interval=$((($BAT_LEVEL -$CRIT) * 120)) # loose estimate of backup time for each percentage of battery charge.
    # Is AC plugged in?
    state='acpi -b |grep -Eo "[A-Za-z]+harging"' 
    #only notify if not Plugged in
    if [ "$state" = "Discharging" ] ; then
        # is battery below CRIT level?
        if [ $BAT_LEVEL -le $CRIT ]; then
        aplay ~/apert.wav &
        notify-send "Battery-Low!!!" -i /home/bibek/batt.png -t 900
        sleep 100  # nag me each 100 secs untill I plug the thing 
        else
            sleep $interval
        fi
    else
        # if plugged in sleep 
        if [ $BAT_LEVEL -le $CRIT ]; then
            sleep $interval
        else
            # to check if the AC is unplugged before battery gains charge above CRIT.
            sleep 100 
        fi
    fi
    done

    

Answer 8

Usar sleep em vez de cron para um único trabalho pode ser mais eficiente. Mas como você geralmente tem cron em execução em qualquer caso, fazer uso disso vem de graça, ou perto o suficiente, como não faz diferença. Então, a menos que você esteja em um sistema integrado, que não seja cron -free, eu usaria cron .