Dariusz Cieślak

Często po zainstalowaniu RoR/Django na VPS-ie OpenVZ zdarza się, że przestajemy mieścić się na serwerze wirtualnym. Proces fastcgi zajmuje w pamięci 70 MB (VSZ) pomimo, że aplikacja nie zawiera jeszcze zbyt wiele funkcjonalności. Winę za tak duże zużycie pamięci witualnej (która jest ograniczona w OpenVZ) jest domyślny rozmiar stosu dla procesu. Pod linuksem domyślnie stos zajmuje 8 lub 10 MB. Należy to przemnożyć przez liczbę wątków w aplikacji i wychodzi duże zużycie pamięci. Rozwiązaniem jest zmniejszenie domyślnego rozmiaru stosu dla aplikacji. W większości przypadków wystarczy tylko 128 KB. Jak to zrobić? Jest kilka rozwiązań: można przed uruchomieniem procesu wydać polecenie "ulimit -s 128" można umieścić ograniczrenia w /etc/security/limits.conf, ale dotyczą one tylko sesji użytkownika (nie będą obowiązywały dla procesów Apache) Najbardziej efektywnym rozwiązaniem będzie jednak umieszczenie tego wywołania w /etc/init.d/rc: "ulimit -s 128". Wtedy zmiana jest widoczna dla wszystkich procesów w systemie. Dzięki tej operacji udało mi się zmniejszyć zapotrzebowanie na pamięć z 248 MB do 83 MB (Apache prefork + PHP + Django), czyli zredukować je o ponad 60%. Sam proces Django FastCGI zajmuje teraz 17 MB, czyli zmiana jest jest znacząca. Więcej szczegółów i "bibliografia": tutaj.

Niektóre aplikacje mogą wymagać większej przestrzeni na stosie do działania. Z moich testów wynika, że 128 .. 256 KB per wątek w zupełności wystarcza. jeśli pojawi się komunikat stack overflow można limit zwiększyć dwukrotnie. Nawet przy 512 KB / wątek jest zysk w stosunku do domyślnej wielkości stosu.

Podejrzewam, że wydajność będzie podobna, ale zaletą konta wirtualnego jest to, że w momencie dociśnięcia serwera nie zostaniesz z niego wyproszony przez adminów (strony po prostu będą trochę wolniej generowane). Przerabiałem przejście shared -> Luna na Kei i jedyną niedogodnością Luny w stosunku do shared był tragicznie długi czas potrzebny na podniesienie maszyny po restarcie (przez pół godziny system był niedostępny a rebooty zdarzały się niestety właśnie w godzinach "biurowych"). Być może teraz nie restartują już hostów VPS w ciągu dnia, tego nie wiem. Ogólnie Lunę/Kei mogę polecić - wydajność (w porównaniu np. do Progreso) bardzo dobra.

Potwierdzam chaos jeśli chodzi o support, ten sam problem z fakturami (dwie zaległe i zero odzewu). Kilkukrotne prośby o regularne uruchamianie ntpdate na hoście nie dały żadnego efektu (zegar sprzętowy "płynie", a z VPS-a OpenVZ nie mogę ustawiać czasu).

Więcej szczegółów: http://www.webhostingtalk.com/showthread.php?t=729727Backupy z października 2008 (!).

Zgadza się, moja pomyłka. RAID1 to miniumum. Wszystko poniżej: można przyjąć, że nawali w ciągu kilku miesięcy (zasada ograniczonego zaufania do platformy).

Z tego co rozumiem ideę oferty Kimsufi: to rezygnują z RAID0 w domyślnej konfiguracji. Gdybym decydował się na taki serwer od razu przygotował bym automatyczny przyrostowy backup i gotową procedurę odtworzenia usługi na innym koncie. SliceHost to dobra marka w cenie której kupujesz ubezpieczenie na wypadek padu dysku (jest RAID0+).

Na początek errata: Tu edytor wyciął mi fragment, powinno być: find . -name \*.html -o -name \*.php | xargs grep "<!-- ad -->" Nie wiem jak jest u ciebie. Na serwerze nie miałem Joomli (tym bardziej niezałatanej) - u mnie podejrzewam wyciek z wirusa na stacji roboczej (keylogger lub wyłuskanie zapisaneych haseł do FTP). Tym bardziej, że wirus skopiował się także na inne serwery do których był dostęp z tego komputera. Czy są jakieś wyniki z analizy logów FTP? Więcej szczegółów na temat wirusa: tutaj.

Niech zgadnę: pojawia się mniej więcej taki wpis: Usunąłem tego wirusa niedawno u mojego klienta i zdiagnozowałem źródło jako wyciek haseł FTP. Wirus na maszynie webmastera przechwycił hasła do FTP i wysłał je na zewnętrzny serwer. Po jakimś czasie nastąpiło połączenie FTP spoza Europy w czasie którego: nastąpiło skanowanie konta w poszukiwaniu plików *.php *.html dla każdego znalezionego pliku: DOWNLOAD / UPLOAD widoczna w transfer.log serwera FTP Sposób usunięcia wirusa: Wywalić wirusy ze stacji roboczych Zmiana haseł FTP dla wszystkich kont Przeskanowanie konta w poszukiwaniu zainfekowanych plików W moim przypadku skanowanie wygląd tak (skrypt CGI na serwerze): am123, proponuję zajrzeć do logów serwera FTP - jeśli znajdziesz tam podejrzane sekwencje DOWNLOAD/UPLOAD łatanie Joomli i zwalanie na progreso niewiele pomoże. Daj znać o wynikach śledztwa (sam jestem ciekawy jaki mechanizm włamu zadziałał u ciebie).

Mam nadzieję, że dla kogoś okaże się przydatny: CmsWiki. CmsWiki jest połączeniem edytora WYSIWYG (na razie jest wparcie dla NicEdit i FCKEditor) i idei dynamicznego tworzenia stron zaczerpniętej z WikiWikiWeb. Autoryzację dostępu do stron edycji pozostawiłem standardowym mechanizmom (.htaccess). Edycja opiera się na HTML (więc bez problemu można wkleić multimedialne klipy np. z YouTube na stronie). System jest prosty, więc dość szybki. Pomiary pokazują wydajność 600 req./sekundę na VPS-ie 400 Mhz. W porównaniu do niektórych systemów zarządzania treścią dla których zmierzyłem 4 req./sekundę jest to dobry wynik. Pozwala obsłużyć znaczne skoki ruchu na stronie. Konfliktowe zmiany wprowadzone naraz przez kilka osób są obsługiwane poprzez mechanizm merge (podobnie jak w CVS/SVN). Nie ma więc niebezpieczeństwa, że przy edycji jednej strony przez kilka osób zmiany zostaną nadpisane.

> Poza tym nie wiem, czy mysqldump + tar zmieści się w 30sek... To zależy od wielkości bazy, ale zakładam, że ktoś kto korzysta z hostingu będzie operował na bazach < 100MB. > A nawet jeśli się wykona, i do tempa gdzieś zapisze plik, to jak go przesłać na zdalny serwer? FTPem? Tak. > Jeśli chcesz to via cgi robić, to przeć to trwa dłużej, niż stdout. Nie, cgi + suexec będzie działać tak samo jak skrypt uruchomiony przez SSH. To samu się tyczy czasu transmisji (z dokładnością do timeoutu nakładanego na skrypty CGI przez serwer WWW). > A jeśli zdalnie wgetem, to jak rozpoznasz, czy skrypt wygenerował (już) poprawny backup? Najprościej: odstęp 10 minut przed odpaleniem FTP get + suma MD5 też leżąca jako plik na FTP którą można zweryfikować po stronie serwera odbierającego backup. Mamy pewność, że dump nie został przerwany i że przetransmitowano cały plik.

Na to też jest sposób. Można backup podzielić na dwie fazy: CGI: przygotowanie pliku *.sql.gz FTP: ściągnięcie pliku Zakładam, że sam mysqldump zmieści się w 30 sekundach (przykładowe ograniczenia na czas wykonania skryptu). Transmisja FTP ze względu na ograniczone pasmo może trwać dłużej.

Niedawno spostrzegłem, że VAServ (CheapVPS.co.uk / a2b2.com) przygotowało nową ofertę VPS: http://fsckvps.com/. Parametry/cena jest dość wysoki (nawet biorąc pod uwagę, że to OpenVZ bez RAID i w US). Co sądzicie? Jest jeszcze jakiś haczyk którego nie zauważyłem?

RPS to rzeczywista maszyna, ale z sieciowym systemem plików. VPS to serwer podzielony na odrębne maszyny wirtualne. Teoretycznie RPS powinien lepiej się sprawować, ale czytałem wiele negatywnych opinii na temat sieciowego systemu plików (SAN) używanego w RPS (głównie dotyczących wydajności), dlatego zdecydowałem się na zakup VPS-a (i nie mam powodów do narzekania). Z drugiej strony pomiary jednego z serwisów opartych na RPS-ie wygądają wręcz wzorowo (czasy są OK, nie ma oznak zamulania odczytów z dysku). Może wypowie się ktoś kto użytkuje takiego RPS-a z OVH?

Proponuję ustawić "LogLevel debug" w konfiguracji Apache i podesłać fragment error.log. To powinno wyjaśnić zagadkę.

Jeśli by zajrzeć do dumpa bazy danych MySQL znajdziesz taką oto linijkę: Jest to deklaracja w jakim kodowaniu jest zapisany ten konkretny plik i podczas ładowania bazy ta informacja jest interpretowana przez klienta mysql. Inna sytuacja to taka, kiedy aplikacja pisała po bazie krzaczkami (zamiast "oficjalnie" wysyłać utf-8), wtedy rzeczywiście odpowiedni skrypt sed musi być użyty do korekty znaczków PL.

To jest dość dziwne. Obstawiam, że serwer Apache nie wysyła w nagłówkach Content-length / użyte proxy z jakiegoś powodu go wywala. Można sprawdzić na poziomie protokołu HTTP czy odpowiedź serwera zawiera ten nagłówek.

W przypadku dedyka na duże ilości danych musisz zapewnić albo regularny przyrostowy backup albo porządny RAID. Według mnie lepiej (taniej) jest skorzystać z SAN (sieciowy system plików) lub z dostawców "raw storage" typu S3 (który i tak siedzi na czymś w rodzaju SAN). Wyobraź sobie co się stanie kiedy miejsce na dysku zacznie się kończyć ...

Dziś dostałem coś takiego: a po chwili: Jak widać Pan Hieronim pracuje w pocie czoła, żeby zabezpieczyć listy e-mailowe portalu gazeta.pl, trzymamy kciuki! ;-)

Do składowania dużych plików proponuję S3. Wychodzi dość ekonomicznie i można zamówić lokalizację w Europie. Na dedyku zawsze dojdziesz do limitu zainstalowanego dysku, w S3 masz nieograniczony rozproszony dysk sieciowy z redundancją. Płacisz dokładnie za to z czego korzystasz.

Ale czy zgodne z prawdą? ;-)

Na podstawowych kontach hostingowych można użyć skryptu CGI: mysqldump do tymczasowego katalogu kopiujemy do tego katalogu także pliki które mają być zbackupowane nagłówek: Content-type: application/octet-stream tar zcf - <katalog-tymczasowy> (backup idzie na stdout) Koniecznie ograniczyć dostęp poprzez .htaccess ! Po stronie drugiego serwera (crontab): wget --user=... --password=... (...) -O backup.tgz

Według Specyfikacji HTTP istotą HEAD jest przesłanie tylko nagłówków z pominięciem treśći odpowiedzi. Nie ma mowy o blokowaniu wykonania skryptu generującego nagłówki i treść. Z mojej praktyki wynika, że niektóre serwisy blokują żądania HEAD, więc siteuptime.com może na nich nie zadziałać.

Zamiast komentarza niech posłuży wynik pomiaru jednej ze stron ich klientów: http://site-uptime.net/su.cgi/report?publi...S4uteetaen3Dai9 Oczywiście strona główna serwisu jest na "lepszym" serwerze: http://site-uptime.net/su.cgi/report?publi...bwurlby9780x2i2 Pozdrawiam.

Jeszcze jedna opinia nt. DH, znaleziona w google: http://drupal.org.pl/node/606