Wiele razy zdarzało mi się, że mój serwer padł całkowicie lub przerywał żądania. Wówczas był niedostępny, a zarobki generowane z serwisów diametralnie spadały. Co więcej… użytkownicy poczuli niestabilność maszyny. Dziś po odpowiedniej optymalizacji kodów aplikacji pady są rzadkością, ale wolę się ubezpieczyć przed niespodziewanym downem serwera.

Problem można rozwiązać w prosty sposób: cyklicznie uruchamiany program bash‘a przez crona będzie odpowiadał za poprawne działanie usługi apache. Listing, który zaprezentuję łączy się z adresem url odwołującym się do naszego serwera za pomocą wget, a następnie wynik działania (response body) zapisze do pliku tymczasowego. Jeżeli plik istnieje oraz ma rozmiar niezerowy, oznacza to, że serwer działa poprawnie. Jeżeli plik nie istnieje, bądź jego wielkość jest równa zero z, oznacza to, że trzeba zrestartować usługę apache, bo nie odpowiada. Zaraz przed zakończeniem programu, plik tymczasowy powinien zostać usunięty. Pozwoliłem sobie opublikować mały program służący do automatycznego restartu usługi apache.

Aby nasz program poprawnie działał, trzeba zastanowić się nad trzema istotnymi rzeczami:

1. Ile prób połączenia ma wykonać wget oraz jakie mogę być timeouty.
2. Czy adres url, do którego się odwołujemy będzie zawsze dostępny w przypadku poprawnego działania usługi apache.
3. Jaki powinien być interwał uruchamiania napisanego programu.

Na moim serwerze program uruchamia się co minutę, próbuje połączyć się ze stroną dwa razy, a maksymalny czas oczekiwania na odpowiedź przy każdej z prób wynosi 10 sekund.

Program zapisany jest pod /root/check_apache.sh, a regułka uruchamiania w cronie wygląda następująco:

* * * * *       bash /root/check_apache.sh

Przedstawiony problem można rozwiązać na wiele sposobów, przedstawiłem ten najbardziej oczywisty.

Pisząc nowy projekt natknąłem na problem z procesem uploadu filmiku do serwisu YouTube. Sam upload jest bardzo łatwy do napisania z Zend_Gdata_YouTube – przykład można znaleźć w manualu. Myślę, że zainteresowani przeczytają manual i wszystko będzie jasne. Więc jeżeli to takie proste, to w czym problem?

Zakładamy, że userzy uloadują filmiki bezpośrednio na nasz serwis. Nasz serwer ma za zadanie:

1. Skompresować video i zapisać go w formacie flv.
2. Nałożyć watermark.
3. Wysłać obrobiony film do serwisu Youtube logując się na zdefiniowane przez użytkownika konto lub założone przez administratora strony.

Pierwsze 2 kroki wykonają się błyskawicznie w porównaniu do trzeciego. Kompresja i nałożenie watermarku na 30 megowy plik z wykorzystaniem FFMPEG to nic nadzwyczajnego. Natomiast wysyłka pliku na serwery Youtube’a może zawiesić apache’a, gdy jest ich kilka.

Rozwiązanie? Wpadłem na pomysł, aby upload filmików ustawiony był w pewnego rodzaju kolejce, która uruchamiana by była co minutę (cron), a czas jednego wysłania elemntu nie mógłby przekroczyć 50 sekund. Oczywiście takie działanie uruchamiałoby swój osobny proces apache’a. Ten sposób jest ograniczony dwoma limitami: wielkością pliku oraz czasem jego uploadu na serwer (jednocześniem interwałem uruchamiania kolejki).

Po przenosinach lookme.pl na nowy serwer, serwis zaczynał coraz częściej się zawieszać. Godziny spędzone przy sprawdzaniu, czy silnik i baza danych została dobrze zoptymalizowana. Wszystko wyglądało w jak najlepszym porządku. W międzyczasie ostro spadaliśmy z bardzo wysokich pozycji w Google. Administrator serwera wyrywał sobie włosy. Wzrost zużycia procesora w przeciągu 10 min skakał od 0.8% – 64%. Uptime apache’a wahał się od 3 – 20 minut.

Na serwerze nazwa.pl tego nie było. Gdy już całkiem rozłożyłem ręce zorientowałem się, że wykonywanie zapytań do bazy danych trwa po 0.0008 sekundy, a mimo tego strona ładuje się po 12 sekund (o ile w ogóle się załaduje). Wyłączyłem cache serwisu.

Gdy odkryłem co zawiesza proces apache’a złapałem się za głowę… Podliczanie plików sesji w celu uzyskania użytkowników on-line. Aby sprecyzować tą liczbę, korzystałem z daty modyfikacji każdego pliku, aby określić, czy był ruszany przez ostatnie 10 min. Jeżeli tak, to zapewne user jest on-line. To nie było zwykłe podliczanie… usunąłem warunek limitu 600 sekund. Licznik wskazał… 472621 plików sesji, które za każdym razem były sekwencyjnie sprawdzane O.o” (co powodowało totalny dead apache’a).

Przyczyna zatrzymania procesu czyszczenia sesji przez defaultowy handler php jest mi do dziś nieznana. Wszystkie wartości odpowiadające za tę czynność były odpowiednio ustawione.

I stałem się szczęśliwym posiadaczem serwera dedykowanego. Podczas przenoszenia dość dużego serwisu fotkowego LookMe.pl oczywiście wystąpiły komplikacje. Ale to już nie po naszej stronie – bo do przerzutu takiego kolosa opracowaliśmy bardzo dokładną strategię.

Po stronie OVH.pl:

Konsultanci z OVH niemile nas zaskoczyli, że dodanie domeny LookMe.pl do secondary DNS nie jest możliwe bo… wpis A na jej temat istnieje juz na nieaktywnym od kilkudziesięciu dni serwerze 720plan. Gdy Panowie tłumaczyli się, że procedura zamknięcia serwera trwa do 15 dni od momentu dostarczenia wniosku, wyperswadowałem im, że potrzebuję dostęp do domeny na teraz. Na szczęście poszli mi na rękę i mimo długiej kolejki zamykania serwerów, moja procedura trwała pół godziny.

Po stronie nazwa.pl:

Administracja chyba sobie jaja robi, że nie można spokojnie ściągnąć bazy danych poprzez phpmyadmin, ponieważ nakładają różnego rodzaju limity na php i cgi. Po interwencji na maila, umieścili kopię na moim serwerze w postaci spakowanego pliku.

Przy imporcie fotek na serwer, konsolowy klient ncftp ciągle zrywał połączenia, bo zostawał odrzucany przez nazwę. Co za różnica, czy wpiszę tak:

ncftp get -r fotki

czy w dwóch paczkach tak:

ncftp get 0* 1* 2* 3* 4* 5* 6* 7*
ncftp get 8* 9* a* b* c* d* e* f*

No jednak, dla nazwa.pl różnica jest, bo ncftp najpierw skanuje to, co ma pobrać, zanim zabierze się do kopiowania plików. Nazwa widząc, że lista jest długa, od razu lub po jakimś czasie odrzucała połączenie. W 2 paczkach jest o 50% mniej plików, pewnie to wystarczyło na obejście jakiegoś kolejnego durnego limitu.

Podsumowanie:

Cóż, obie firmy nie są wporządku, ale dlaczego dopiero po napisaniu maila?

Od kilku dni moje serwisy stoją już na nowym serwerze Active w nazwa.pl. Jak zarazie pozytywne wrażenia, co więcej – zdziwiło mnie że kilka naprawdę dużych serwisów jest w stanie działać na zwykłym (niededykowanym) serwerze.

Plusy serwera Active:

• Stabilność.
• Powiadomienia o planowanych pracach konserwacyjnych.
• Krótkie prace konserwatywne.
• Błyskawiczna odpowiedź od administratora drogą elektroniczną.
• Analiza obciążenia powodowanych przez poszczególne komponenty serwisu.

Minusy:

• Sabie rozbudowane drzewo dostępu do domen, trzeba sobie samemu tworzyć struktury: /domains/domena/public/ oraz /domains/domena/subdomains/subdomena/public/
• Bardzo ubogie możliwości zakładania skrzynek pocztowych – każdy login działa w każdej domenie jaka istnieje na serwerze, przykładowo konto example będzie działało tak samo dla example@domena-pierwsza.pl i example@domena-druga.pl
• Transfer 1Tb/6mc – kiedy wykorzystuję około 600 Mb dziennie. Chyba niedługo czas przejść na wyższy pakiet : ).

Neutralne:

• Za wpisy DNS na serwer odpowiedzialny jest administrator, trzeba mu wysłać listę domen na serwerze, aby dodał je ręcznie do configu (brak automatyzacji). Usprawiedliwiającym jest fakt, że oczekiwanie na nową domenę trwa od 5 – 20 minut w godzinach roboczych.