Jak zaplanować zadania serwera w bardziej inteligentny sposób niż z cronem?


15

Co minutę uruchamiam zadanie, aby ponownie zindeksować treść mojej witryny.

Dzisiaj umarła wyszukiwarka, a kiedy się zalogowałem, były setki sierocych procesów zapoczątkowanych przez crona.

Czy istnieje inny sposób korzystania z istniejącego oprogramowania, które pozwoli mi wykonywać zadanie co minutę, ale nie uruchomi innej instancji, jeśli zadanie to nie zwróci (tj. Ponieważ proces wyszukiwarki nie powiódł się)?


4
cron najprawdopodobniej robi dokładnie to, co mówisz. Zamiast tego sugeruję inteligentne przepisanie pracy.
gparent

Odpowiedzi:


27

Problem tak naprawdę nie dotyczy crona - dotyczy twojej pracy.

Będziesz musiał współpracować z blokadą jakiegoś opisu. Najłatwiej to zrobić, próbując utworzyć katalog, a jeśli się powiedzie, kontynuuj, jeśli nie, zakończ. Po zakończeniu i zakończeniu zadania powinno ono usunąć katalog gotowy do następnego uruchomienia. Oto skrypt do zilustrowania.

#!/bin/bash

function cleanup {
    echo "Cleanup"
    rmdir /tmp/myjob.lck
}

mkdir /tmp/myjob.lck ||  exit 1
trap cleanup EXIT
echo 'Job Running'
sleep  60
exit 0

Uruchom to w jednym terminalu, a następnie, zanim upłynie 60 sekund, uruchom go w innym terminalu, zakończy działanie ze statusem 1. Po zakończeniu pierwszego procesu możesz uruchomić go z drugiego terminala ...

EDYTOWAĆ:

Kiedy właśnie dowiedziałem się o stadzie, pomyślałem, że zaktualizuję tę odpowiedź. flock (1) może być łatwiejszy w użyciu. W takim przypadku flock -nwłaściwe wydaje się np

* * * * * /usr/bin/flock -n /tmp/myAppLock.lck /path/to/your/job   

Uruchamia się co minutę, ale kończy się niepowodzeniem, jeśli stado nie może uzyskać blokady pliku.


2
Głupie pytanie, ale czy korzystanie z katalogu jest bardziej przydatne niż zwykły plik?
gparent

9
Korzystanie ze zwykłego pliku wymaga kilku operacji, sprawdź, czy istnieje, a jeśli go nie utworzy. Pozostawia to możliwość innym procesowi utworzenia pliku - niechlujnym. Mkdir to operacja atomowa, która albo działa i dostajesz „blokadę”, albo nie, ponieważ już ma go inny proces.
user9517

Ma sens. Dobre myślenie także w katalogu blokady. Dzięki
John

2

Jednym ze sposobów może być utworzenie przez skrypt reindex pliku blokady, aby mógł sprawdzić, czy jest już uruchomiona instancja skryptu. Możesz także dodać obsługę wyjątków, aby sprawdzić, czy wyszukiwarka jest uruchomiona.

Bardziej zaangażowaną alternatywą byłoby użycie pewnego rodzaju kolejki zadań, takiej jak Resque i Resque-scheduler:

https://github.com/blog/542-introducing-resque

https://github.com/bvandenbos/resque-scheduler#readme

Są też Qu i Sidekiq:

https://github.com/bkeepers/qu

https://github.com/mperham/sidekiq

Tak, to wszystko zorientowane na Ruby, ale możesz szukać „rzeczy takich jak resque” w wybranym przez siebie języku.


0

Innym sposobem na szybką konfigurację jest uruchomienie skryptu powłoki podczas uruchamiania komputera (cron może to zrobić za pomocą „ @reboot /path/to/my/script.sh”,., A następnie zrestartować crona, aby go uruchomić) z czymś takim.

#!/bin/sh
/opt/bin/run-site-index
sleep 60
exec $0

Skrypt nadal działa, a jeśli dopiero go uruchomiłeś - tyle może być uruchomionych jednocześnie - nie więcej. Niektóre inteligentne urządzenia mogą również sprawdzić, czy indeksator jest uruchomiony, a jeśli nie, zrestartować lub w inny sposób spróbować naprawić / powiadomić kogoś o problemie.


-3

Zamiast używać do tego crona, zbudowałbym twoją pracę bardziej jako usługę, która działa w pętli i śpi przez 60 sekund jako ostatni krok, a może śpi częściej w mniejszych odstępach czasu w różnych punktach procesu, aby pomóc w rozłożeniu obciążenia bardziej równomiernie.


1
Nie rozwiązałoby to ani problemu, ani usprawnienia ze strony crona.
gparent

Rozwiązałoby to problem, ponieważ wtedy istnieje tylko jeden proces, który zawsze działa. Całkowicie ominąłby crona.
Joel Coel,

Nie rozwiązuje problemu, jeśli „usługa” nie sprawdza, czy wyszukiwarka jest uruchomiona. Problemem jest logika jego skryptu / zadania. EDYCJA: Właściwie masz trochę racji, ukryłoby to problem w brzydki sposób.
gparent
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.