Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Powielanie procesów przez crona
Forum PHP.pl > Forum > PHP
auto-all
Witam

Problem polega na tym iż wskazany plik uruchomiony jest równocześnie przez kilka procesów.

Czas wykonania pliku zależy od ilości danych znajdujących się na serwerze, czasami będzie to 30sek a czasami dużo więcej niż ustawienie max_execution_time i skrypt zostaje zabity w trakcie działania.

Chciałbym zabezpieczyć aplikację na tyle aby takie sytuacje się nie zdarzały. Zarówno dla crona jaki dla uruchomień z przeglądarki (te drugie jak mniemam może być niewykonalne)

Poszukuje czegoś bardziej zaawansowanego niż ustawienie max_execution_time i set_time_limit() gdyż chce aby skrypt przetwarzał dane non-stop - 24/7 - a przy ustawieniu max_execution_time na 300 a gdy proces wykona się w 90sek. to mam niewykorzystane 210sek.

Zadania crona i ich powielanie (uruchamianie następnych gdy poprzedni jeszcze się nie zakończył)

Myślałem nad czymś takimi ale nie bardzo wiem czy to wykonalne i w jaki sposób można to osiągnąć:
1. Sprawdzanie czy działają jakieś procesy związane z tym plikiem, komendą, numerem ID rodzica.
2. Jeśli jakieś by wykrył to miałby czekać na zakończenie procesu, kończyć działanie (swoje) lub kończyć działanie procesu, który wykrył.
3. Po zakończeniu działania uruchomienie komendy za pomocą exec() w tle.

Skrypt działa na serwerze dedykowanym także nie ma ograniczeń w kreatywności.

Czekam na jakieś sugestie. Jak wy radzicie sobie z zadaniami, które serwer ma przetwarzać non-stop?
batman
W przypadku cron-ów sprawdza mi się następujący sposób:
1. Cron odpala skrypt.
2. Skrypt sprawdza czy istnieje plik przyklad.txt
3. Jeśli pliku nie ma, zostaje on utworzony, a skrypt mieli co ma mielić. Jeśli plik jest, ubijam skrypt.
4. Na końcu skryptu plik jest usuwany.

W przypadku błędu uniemożliwiającego usunięcie pliku, podczas sprawdzania jego istnienia, sprawdzam czas jego utworzenia. Jeśli czas ten przekracza z góry ustaloną wartość, plik jest usuwany, a skrypt leci dalej.

Możesz również pokusić się o napisanie daemona.
phpion
@batman:
Od tworzenia i usuwania pliku lepiej sprawdza się zakładanie blokady na plik. W przypadku, gdy skrypt zakończy swą pracę (w sposób naturalny lub się wysypie) blokada jest automatycznie zdejmowana. Polegając na sprawdzaniu istnienia pliku jeśli w międzyczasie skrypt się wysypie to plik nie zostanie usunięty i będzie trzeba to zrobić ręcznie. Zakładanie i zdejmowanie blokady automatyzuje ten proces. Czyli: jeśli blokada jest założona proces pracuje, jeśli jej nie ma - proces nie pracuje.
batman
@phpion
Tworzenie pliku ma tę przewagę, że jeśli skrypt się wywali, potencjalnie niebezpieczna operacja nie wykona się ponownie, ponieważ będzie istniała blokada w postaci pliku. W tym czasie osoba odpowiedzialna za skrypt otrzyma powiadomienie, że coś się wysypało i zdąży zareagować. W Twoim scenariuszu skrypt będzie się wywalał za każdym razem. Oczywiście wybór sposobu zależy od kontekstu i nie da się jednoznacznie stwierdzić, że któryś jest lepszy lub gorszy.
Pliku nie trzeba ręcznie usuwać, ponieważ o to zadba sam skrypt, który sprawdzi czy plik został utworzony jakiś czas temu i sam go usunie, jednocześnie dając czas na usunięcie problemu.
phpion
W sumie masz rację - wszystko zależy od konkretnego przypadku. Wydaje mi się jednak, że w większości przypadków lepiej sprawdzi się rozwiązanie z blokadą na plik. Przykładowo w systemie mailingu: jeśli podczas próby wysyłki skrypt się wysypie to przy następnym uruchomieniu automatycznie nastąpi próba ponownej wysyłki wiadomości. Co do możliwości zareagowania przez osobę odpowiedzialną za skrypt: co jeśli takowa osoba aktualnie śpi albo jest na urlopie? smile.gif
batman
Cytat(phpion @ 17.02.2012, 10:17:52 ) *
co jeśli takowa osoba aktualnie śpi albo jest na urlopie? smile.gif

To ma pecha i musi wstać albo zwlec się z plaży smile.gif
MLukasz
Lepsze od samodzielnego tworzenia plików-flag byłoby zapięcie tego w cronwrapa smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.