cron vs. sleep - który jest lepszy pod względem efektywnego wykorzystania procesora / pamięci?

Walizka:

Muszę uruchamiać niektóre polecenia / skrypt w określonych odstępach czasu i do tego mam dwie opcje:

1. utwórz cron-Job
2. zaimplementuj pętlę sleepw samym skrypcie.

Pytanie:

Jaka jest lepsza opcja z punktu widzenia zużycia zasobów, dlaczego? Czy cronjest lepszy sposób? Czy cron używa jakiegoś wyzwalacza lub czegoś, co czyni go wydajniejszym w stosunku do drugiego? Jakiej procedury używa cron do sprawdzania i uruchamiania zadań?

Użyj crona, ponieważ jest to lepsza i bardziej standardowa praktyka. Przynajmniej jeśli jest to coś, co będzie regularnie działać (nie tylko coś, co załatałeś razem za minutę). cronjest czystszym i bardziej standardowym sposobem. Jest to również lepsze, ponieważ uruchamia powłokę odłączoną od terminala - nie ma problemu z przypadkowym zakończeniem i zależnościami od innych procesów.

Jeśli chodzi o zasoby: CPU: oba procesy śpią - kiedy śpią, nie marnują procesora. cronbudzi się częściej, aby sprawdzić rzeczy, ale i tak to robi (nie więcej dla twojego procesu). Jest to niewielki ładunek, większość demonów budzi się czasami. Pamięć: Prawdopodobnie crondziałasz niezależnie od tego procesu, więc nie jest to w ogóle narzut. Jednak cron uruchomi powłokę dopiero po wywołaniu skryptu, podczas gdy skrypt pozostanie załadowany do pamięci (proces bash ze środowiskiem - kilka kilobajtów, chyba że ładujesz wszystko do zmiennych powłoki).

Podsumowując, dla zasobów nie ma to znaczenia.

Użyj cron(lub anacron).

Cron jest zaprojektowany do pracy w odstępach czasu. To jedyna rzecz, jaką robi, i wiele lat włożono w cron, aby uczynić go takim, jakim jest dzisiaj.

Szanse, że napiszesz w swoim skrypcie lepszy harmonogram, są praktycznie zerowe. Używanie crona będzie działało lepiej, unikaj niepotrzebnego kodu w skrypcie i utrzymuj kod zwięzły i łatwiejszy w utrzymaniu.

Nie wymyślaj koła ponownie, jeśli nie musisz.

Istnieje już kilka dobrych odpowiedzi croni sleepwydajności, ale chcę dodać jakieś porównanie funkcji.

Pro cron:

• działający już w systemach Unix / Linux
• stabilny i sprawdzony
• przeznaczony do procesów w tle
• działa od uruchomienia systemu, podobnie jak skrypt po zainstalowaniu
• łatwiejsze wprowadzanie cykli długoterminowych (godziny, dni, tygodnie)
• pozwala na złożone długoterminowe powtórzenia („co drugą niedzielę o 5:35”)

Pro sleep:

• łatwiejsze do utrzymania w skrypcie
• łatwiejsze dla procesów pierwszego planu
• umożliwia czasy snu krótsze i bardziej precyzyjne niż minutę
• pozwala na złożone cykle snu / akcji („uruchom tę część, następnie spij 10 sekund, a następnie uruchom drugą część i śpij dwie godziny”)

Czy cron używa jakiegoś wyzwalacza lub czegoś, co czyni go wydajniejszym w stosunku do drugiego?

Rzuciłem okiem na cat /proc/`pidof crond`/stack. Po wydrukowaniu go kilka razy z rzędu widzę, że crondpo prostu śpi w 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

sleep Narzędzie używa tego samego wywołania systemowego.

>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

Zakładam, że oba narzędzia ( crond& sleep) muszą mieć niskie wykorzystanie procesora i jeśli musisz naśladować, cronto zdecydowanie możesz z nich korzystać sleep.

Aktualizacja. Lepiej jest obserwować crondaktywność za pomocą

strace -p `pidof crond`

Główną różnicą, której szukasz, jest to, że cronnie działa stale. Jak wyjaśniono w 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.

Innymi słowy, cronbędzie uruchamiany tylko raz na minutę i sprawdzi, czy należy go uruchomić. Z drugiej strony twoje podejście do snu wymagałoby twojego rzeczywistegosleep polecenia, powłoki, terminala i whilepętli (lub cokolwiek innego).

Nawet gdyby uruchomili tę samą liczbę procesów, cronbyłoby lepiej. Zostało to napisane właśnie dla tego przez ludzi, którzy zwykle są bardzo dobrzy w swojej pracy. Z pewnością zrobi to lepiej niż zwykła pętla powłoki.

Różnica polega na tym, że wraz z dodawaniem kolejnych skryptów, które muszą spać, skończy się czekanie na więcej procesów zamiast jednego procesu (cron), który budzi się i uruchamia zaplanowane skrypty, które następnie zamykają się do następnego uruchomienia. Cron pozwala na jeden proces, który jest wyspecjalizowany w uruchamianiu innych skryptów na czas, a ponadto cron pozwala stosunkowo swobodnie planować, kiedy coś powinno zostać uruchomione, dni tygodnia lub miesiąca, określone godziny lub tylko co 5 minut itp.

* Ponowne zobaczenie tego przypomniało mi kolejną zaletę crona. Wszystkie skrypty uruchamiane okresowo znajdują się wtedy w jednym miejscu, a stamtąd można łatwo sprawdzić, kiedy i jak często będą uruchamiane. W przeciwnym razie musisz sprawdzić poszczególne skrypty.

Są już dobre i bardziej świadome odpowiedzi, ale chciałem tylko zauważyć, że dzięki temu sleepmożna zamrozić proces na różny czas, powiedzmy jako funkcję niektórych innych zmiennych.

Jeśli piszę skrypt, aby sprawdzić procent pozostałej baterii i notify-sendjeśli jest ona poniżej z góry określonego poziomu krytycznego, mogę wykonać skrypt sleepna czas, który jest funkcją bieżącego poziomu baterii w procentach, zamiast sprawdzania baterii co jedna lub dwie minuty z pomocą crona, nawet gdy wiem, że było 80%, kiedy ostatnio sprawdzałem.

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

Korzystanie sleepzamiast cronjednego zadania może być bardziej wydajne. Ale ponieważ zazwyczaj masz cronbieganie w każdym przypadku, korzystanie z niego przychodzi za darmo lub wystarczająco blisko, ponieważ nie ma znaczenia. Więc jeśli nie korzystasz z cronsystemu wbudowanego, który w przeciwnym razie byłby wolny, wybrałbym cron.