auto-all
16.02.2012, 15:56:27
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
16.02.2012, 16:25:06
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
16.02.2012, 16:34:08
@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
16.02.2012, 18:13:08
@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
17.02.2012, 10:17:52
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?
batman
17.02.2012, 10:30:26
Cytat(phpion @ 17.02.2012, 10:17:52 )

co jeśli takowa osoba aktualnie śpi albo jest na urlopie?

To ma pecha i musi wstać albo zwlec się z plaży
MLukasz
18.02.2012, 11:58:31
Lepsze od samodzielnego tworzenia plików-flag byłoby zapięcie tego w cronwrapa
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.