Podzielenie zasobożernej operacji na kilka kroków, problem Opcje

[vee]

Witam,

Pewnego dnia stanąłem przed potrzebą zrobienia kopii ogromnej bazy danych oraz jeszcze większej ilości plików.
Ponieważ nie mam dostępu do SSH, postanowiłem wykorzystać unixowe komendy przez PHP:

[PHP] pobierz, plaintext 
exec('cp ...');
[PHP] pobierz, plaintext 

ze względu na dużą objętość danych, na których te operacje będą przeprowadzane, skrypt się wykrzaczał. Postanowiłem wtedy podzielić go na kilka kroków, dla przykładu
1. dump bazy danych
2. wgranie dumpa do innej bazy danych
3. kopia plików

[PHP] pobierz, plaintext 
<?php
$tmp = file_get_contents('tmp.txt');
if($tmp = 'step1')
{
...
file_put_contents('tmp.txt', 'step2');
header('Location: plik.php');
}
elseif($tmp = 'step2')
{
...
file_put_contents('tmp.txt', 'step3');
header('Location: plik.php');
}
elseif($tmp = 'step3')
{
...
file_put_contents('tmp.txt', 'step1');
}
[PHP] pobierz, plaintext 

jak widać po wykonaniu "kroku" zapisuję w pliku tymczasowym jaki krok jest następny oraz wysyłam nagłówek header('Location: plik.php') celem odświeżenia - wtedy wykonać ma się następny i następny krok.

Mój problem polega na tym, że dopóki testuję to z zakomentowanymi liniami odpowiedzialnymi za w/w operacje (zostaje samo "przechodzenie do nast kroku") - wszystko chodzi dobrze, w firebugu widać dokładnie, że wszystkie kroki się wykonują.

Problem pojawia się, gdy odkomentuję właściwy kod, tzn w momencie kopiowania jakiegoś bardzo dużego katalogu, lub podczas wykonywania innej, potrzebującej sporo czasu do ukończenia, operacji - praca jest przerywana, tzn. nie wysyła nagłówka o przekierowaniu, w pliku TMP mam elegancko wskazane na jakim kroku przerwało pracę.

Dodam, że limit czasu ustawiony na "0", raportowanie błędów mam włączone- jednak takie nie zostają wyświetlane.

Ma ktoś jakiś pomysł, dlaczego tak się dzieje i jak temu zaradzić?

Pozdrawiam

EDIT: Dodam, że na każdy krok przydzielona jest tylko jedna komenda uniksowa, tzn w jednym kroku jest tworzony dump bazy, w drugim jest on wgrywany do innej bazy, w trzecim np kopia plików z... do... itd.

Ten post edytował vee 18.01.2012, 13:49:00

[Uriziel01]

Jesteś pewny że to przekroczenie czasu ?
Dla pewności daj wynik z:

[PHP] pobierz, plaintext 
ini_get('max_execution_time');
ini_get('max_input_time');
[PHP] pobierz, plaintext 

Jesteś pewny że to nie przekroczenie limitu pamięci albo błąd w tym `zakomentowanym` kodzie ? Może pokaż choć po części co tam się znajduje ? W logach serwera/php niczego nie widać ?

Ten post edytował Uriziel01 18.01.2012, 14:15:43

[vee]

Krok, który się wywala najczęściej to:

[PHP] pobierz, plaintext 
 exec('cp katalog1 katalog2'); 
[PHP] pobierz, plaintext 

gdzie katalog1 jest, krótko mówiąc, ogromny. Poza tym exec'iem, zapisem następnego kroku do tmp.txt oraz wysłaniem nagłówka - w tym kroku nie jest wykonywane nic więcej. No i oczywiście na początku włączenie pokazywania błędów i limit czasu "0".

Var dump podanych przez Ciebie linijek :

Kod

string(1) "0" // max_execution time
string(2) "-1" // max_input_time

Pozdrawiam

[by_ikar]

http://sypex.net/en/ <-- możesz podłączyć to chyba nawet pod crona, jak nie masz nawet tego na serwerze, to może to być webcron, które są dostępne w necie za free (webcron.pl chociażby). Zrobi ci pięknie kopie nawet dość dużej bazy. Tyle w przypadku bazy, w przypadku plików, to IMO lepiej nie zaprzęgać do tego php, core systemu możesz machnąć w php, taki dużo przeważnie nie ma. Ale jakieś zewnętrzne obrazki, to już lepiej robić czym innym niż php. Jak możesz listować katalog z obrazkami, to wystarczyć ci będzie sam wget, który może pobrać wszystko rekursywnie, lub poprostu odpalić ftp z konsoli.

[vee]

Niestety zewnętrzne rozwiązania odpadają z kilku względów - min konieczność ochrony danych, na których przeprowadzane są owe operacje. Poza tym szef nalega aby było to rozwiązanie w 100% stworzone (udokumentowane oraz opisane) przeze mnie (głównie ze względu na późniejszą modyfikację/modernizację kodu, oraz rzeczoną ochronę informacji).

Możliwe aby to usługodawca przykręcał nam "kurek" jeśli chodzi o generowane obciążenie? Czy PHP wyplułoby z siebie jakiś błąd w takiej sytuacji?

EDIT: Dodam, że wcześniej rozwiązane było to w taki sposób, że CRON wykonywał skrypt raz dziennie (z dnia na dzień wykonywany był krok po kroku) i wtedy również wywalało się to na bardziej obciążających operacjach.

Ten post edytował vee 18.01.2012, 14:29:24

[Uriziel01]

Hmmm, a na czym to stoi ? Bo widząc `przykręcał nam "kurek"`, jakiś VPS ? Może jakich guardian zamyka proces w trakcie jego trwania bo przekroczył limit czasu ?

[vee]

Niestety wciąż home.pl, jest to jedyna tak "niestandardowa" operacja, więc przeskakiwanie na serwer dedykowany tylko z tego powodu niestety nie wchodzi w grę
Każde inne wykorzystanie serwera nie wychodzi poza jakieś standardy, właściwie to są to proste strony/portale nie generujące specjalnie dużego transferu czy ruchu.

Jeśli chodzi o zamykanie procesu w trakcie jego trwania, nie wydaje mi się to prawdopodobne, ponieważ skrypt wysypuje się po różnych czasach trwania, przeważnie na kroku, gdzie przeprowadzane jest kopiowanie plików. Oczywiście miejsce na serwerze jest, błędów żadnych nie wyświetla.


EDIT:

Chyba dopatrzyłem się dlaczego tak się dzieje - nie wiem dlaczego, ale przegapiłem następujące.
Zwrot z metody CP ląduje w nagłówkach, oto co widzę:

"cannot create regular file `/sciezka/sciezka/sciezka/sciezka/settings.php': Permission denied"

powyższe powtarza się dla wszystkich plików, z ograniczeniami dostępu. Czy jest możliwe skopiowanie za jednym zamachem zarówno tych plików (z ograniczeniami) jak i tych "publicznych"? Jak poprzez FTP dla pojedynczego pliku ustawiłem CHMOD na 777 - nie pojawił się on w zwrotnym nagłówku, jednak takie rozwiązanie niestety odpada - mowa o kilkuset plikach.

EDIT2: oczywiście nie mogę się zalogować jako ROOT więc to rozwiązanie odpada. Jeśli się nie da skopiować tych plików ze względu na uprawnienia, to czy można zrobić to tak, żeby operacja pomimo tych błędów była dalej wykonywana?

Ten post edytował vee 18.01.2012, 14:51:59

[adbacz]

A masz jakoś ładnie ułozony, stworzony katalog/katalogi z tymi plikami? Jesli tak, to najpeirw przeleć po plikach ustawiając im odpowiedni CHMOD (777), za pomocą funkcji php chmod(), a dopiero później je przenoś/kopiuj.

[abort]

1. Jak nigdy nie jestem zwolennikiem instrukcji "system", tak właśnie tu do zmiany praw dostępu bym właśnie to zastosował.

[PHP] pobierz, plaintext 
system ('chmod -R [prawa] [ścieżka]', $ret_val);
[PHP] pobierz, plaintext 

2. Drobna uwaga... Piszesz, że przez FTP jesteś w stanie zmienić prawa i wszystko jest OK. Czy możesz podać usera, grupę i prawa dostępu dla plików, które nie chcą się skopiować, zanim im nie zmienimy praw?
3. Kontynuując punkt poprzedni: utwórz jakiś plik via apache/php (albo wykorzystaj ten plik TMP opisywany wcześniej), jak również wgraj plik normalnie przez klienta FTP. Porównaj wartości usera, grupy i praw do w/w plików, pomoże Ci w tym instrukcja fstat

Przy okazji: "ogromna baza", "jeszcze większa ilość plików" - czy mógłbyś choć trochę przybliżyć wartości, o których piszesz?

[vee]

Problem uprawnień rozwiązany;
Główny problem jednak wciąż występuje. Skrypt wciąż przerywa pracę podczas kopiowania plików. W nagłówkach tym razem nie ma żadnej wskazówki (przerywa na innym kroku).
Co do rozmiaru plików... możliwe, że jest związek z tym, jednak tym razem wywala się na mniejszych katalogach. Co dziwne, kopie plików przeprowadzane są raz na jednym katalogu, a następnie na drugim. Pierwszy katalog jest o wiele większy, jednak to na drugim się wywala. Oczywiście kopie te są podzielone na oddzielne "kroki".


Operacje są na katalogach nieprzekraczających 1GB (pierwszy i drugi katalog). Okolice 800MB. W tej chwili trudno jest mi ustalić dokładny rozmiar tych danych. Bazy zajmują po 600-700Mb, ale z nimi póki co nie ma problemu.

[adbacz]

A nie mozesz zrobić najpierw jednego kroku, później następnego i tak dalej, ale w osobnych skryptach? Powiedzmy, zrobić tyle plików /spep-n.php ile masz króków, gdzie n to następny krok. W tedy mógłbyś zrobić wszystko po kolei, i głowić się tylko nad tym zadaniem, które nie chce się zrobić, powiedzmy /step-2.php. Warto rozbić takie zadania na mniejsze, żeby zobaczyć czego dokładnie problem dotyczy.

[piotrooo89]

wiec możesz to zrobić za pomocą nice i przekierowanie do /dev/null, czyli tak:

Kod

nice -n 19 cp cos_tam cos_tam > /dev/null &

coś takiego obniża Ci priorytet, wykonania i nie zajedziesz serwera dzięki czemu możesz wykonać 100 taki operacji i nie powinno zajeżdżać maszyny. no a wyjście przekierowujesz do /dev/null więc php nie czeka na odpowiedz.

[vee]

@piotrooo89
Ok, komendy wykonują się piorunem, jednak czy mam jakąkolwiek pewność, że nie zostały one przerwane w połowie? Tzn czy mogę jakoś potwierdzić, że cała operacja przebiegła pomyślnie? Bo ręczne przeglądanie tych plików może być uciążliwe... Chodzi mi o możliwość zapisania do pliku informacji po ukończeniu tych operacji - to możliwe czy nie bardzo?

Ten post edytował vee 19.01.2012, 13:31:17

[piotrooo89]

no możesz w samym php zapisać ile plików miałeś na początku (przed kopiowaniem) i sprawdzić go z ilością plików po skopiowaniu.

[vee]

Mógłbyś mi jeszcze odpowiedzieć na takie pytanie, ponieważ nie jestem pewien a może będziesz wiedział.

czy do polecenia:
mysql -u user--password=pass -h localhost nazwabazy < plik.sql

lub
mysqldump -u user --password=pass -h localhost --opt nazwabazy> plik.sql

mogę dopisać to "> /dev/null &", tak aby PHP nie czekał na odpowiedź serwera?

[piotrooo89]

tak, możesz tak zrobić, każde polecenie możesz kierować do /dev/null i wtedy php nie oczekuje na zakończenie, ale nie wiem czy się opłaca z tym importem, bo może się tak stać że będziesz miał niespójne dane, bo w trakcie importu ktoś coś będzie dodawał, ale to nie jestem pewnie jak działa bo nie robiłem nigdy czegoś takiego.

[vee]

Może uściślę, czysto dla pewności - w przypadku mysqldump mam 100% pewności, że kod SQL wyląduje we wskazanym pliku a nie w /dev/null? Polecenia te będą wykonywane o takiej porze, że nie będzie zagrożenia niespójności danych (poza godzinami pracy).

[piotrooo89]

wydaje mi się na 99.99% że będzie ok:

Kod

mysql < sql.sql > /dev/null &

taki plik zaimportuje do mysql i wszystkie komunikaty zostaną przekierowane do /dev/null i dodatkowo polecenie zostanie wykonane w tle (&).

[vee]

Dla potomnych - pliki SQL, w których miał znajdować się zrzut bazy danych były puste po dodaniu "> /dev/null &". Na szczęście przesiadamy się jednak (po wielu moich naciskach:)) na serwer dedykowany, z dostępem przez SSH więc nie powinno być problemu już.

Pozdrawiam i dzięki wszystkim za pomoc!

Ten post edytował vee 20.01.2012, 08:13:54