Dariusz Cieślak

Polecam jeszcze opcję duplicity - backup jest składowany w plikach tgz. Można nałożyć szyfrowanie, więc backupy są bezpieczniejsze.

Tak się składa, że jestem na bieżąco. Przy akceptacji faktur elektronicznych przelew na konto jest za darmo (dotyczy tylko banków w Polsce i tylko w PLN). DotPay oszczędza wtedy na koszcie wydruku i wysyłki faktury pocztą tradycyjną.

Ja bym rzekł, że to jest zalecane. Koszt jest wyższy, ale łatwiej jest niezależnie przełączać dostawców dla tych dwóch usług. Jeśli np. serwer WWW "nie wyrabia" to migracja na nową maszynę nie będzie mieć wpływu na pocztę.

Zwykle nazwa konta to pierwsza litera imienia + nazwisko, jako alias imie "." nazwisko (przydatne jeśli ktoś chce "na ślepo" dotrzeć do jakiejś osoby w firmie). Spotkałem się jeszcze z aliasem: pierwsza litera imienia + dwie początkowe litery nazwiska (bardzo wygodne i skrótowe).

Ja też +1 dla kei (pomimo kilku drobnych wpadek, które mieli). Jako pierwsi w Polsce (chyba) wprowadzili pomiar zużycia CPU w shared hostingu (co trzyma load maszyn na przyzwoitym poziomie). Wyniosłem się od nich ponieważ zacząłem "wystawać" transferem.

Kupując maszynkę z 256 MB RAM gwarantowane w OpenVZ wylądowałem na hoście (openvz-02.statnet.pl, PL). Na podstawie analizy logów które były (przypadkiem) widoczne po HTTP oszacowałem liczbę "sąsiadów" na 20 (to nauczka, żeby zawsze wyłączać moduł userdir pod lighttpd ;-) ). Jakie to są konta i ile maszyna bazowa ma RAM-u można tylko zgadywać. Host raczej nie swapuje, widać to na statystykach vmstat mojej maszyny wirtualnej (niski iowait). CPU też nie jest dociążone (mam spory zapas mocy). Jak na razie (odpukać) prezentuje się pozytywnie.

RSS to w uproszczeniu pamięć zaalokowana z której nastąpił odczyt lub zapis. VSZ to pamięć zaalokowana (można zaalokować więcej niż się w rzeczywistości używa).

Patrząc na aktualne zużycie pamięci VSZ przez proces "oracle" u mnie na laptopie (851 MB) w stosunku do RSS (65 MB) sugeruję poszukac opcji Xen a nie OpenVZ. Będzie mniej niespodzianek z alokacją pamięci.

Musiały by znajdować się w tej samej serwerowni żeby opóźnienia wprowadzane przez sieć nie dawały się we znaki (nie mówiąc już o dodatkowym transferze generowanym pomiędzy bazą danych a maszyną z serweren WWW). Według mnie taka konfiguracja się nie kalkuluje.

Szczegóły (interwał 15 minutowy). Padło około 18:30, wstało około 21:00.

Jeśli chodzi o optymalizację pod kątem zużycia pamięci mogę polecić artykuł na LowEndBox (głównie tyczy się to środowisk małych VPS). Może się też przydać kiedy pod dużym obciążeniem dedyk przestanie się wyrabiać z RAM-em.

Może kogoś zainteresuje: przygotowałem recenzję serwera VPS zamówionego w vpsinn.pl. Na razie jeszcze nie mam pełnych statystyk jakości sieci ani samej platformy - pojawią się kilka tygodni po uruchomieniu kilku usług na tym serwerze.

Tego typu wątpliwości rozwiewa pomiar z innego serwera. Gdyby problemem był "odczyt z dysku" to problem byłby widoczny niezależnie od lokalizacji stacji pomiarowej.

Pakiety idące przez ten router mają losowe opóźnienia dające średni czas dostępu rzędu 200 ms (podczas gdy najlepszy czas przelotu pakietu do Krakowa to 12 ms). Widać to zresztą na wykresie czasu odpowiedzi (wykres jest "poszarpany"). Znacznie lepsze jest wyjście przez z-atman-iwacom2.pl. Obserwacje z Niemiec dają średni czas 70 ms przy czasie minimalnym 50 ms. Jak widać rozrzut jest znacznie mniejszy. System monitorowania z którego korzystam a który cały czas rozwijam (site-uptime.net) obrazuje zarówno problemy z wydajnością serwera pod obciążeniem jak i defekty w konfiguracji sieci.

Taką kombinację oferuje http://fivebean.com na shared (oparte o CPanel).

W Kei.pl dostajesz szczegółową informację w panelu które skrypty zużywają CPU. U Twojego dostawcy jak widzę nie ma takiej informacji. Proponuję więc przenosić/blokować poszczególne serwisy i obserwować zużycie CPU przez procesy na Twoim koncie (top/ps: zakładam, że mają coś na kształt suexec zainstalowane). Czasami wielkość access-logów może być skorelowana z zużyciem CPU, ale nie jest to reguła (rzadko wywoływany skrypt może równie dobrze obciążać serwer).

Jeśli PHP się zapętla to potrzebujesz ograniczyć maksymalny czas generowania odpowiedzi przez skrypt. Czy to jest ta dyrektywa tego nie wiem - należy poszukać w dokumentacji. Jeśli mam na serwerze jakiś "losowy" problem to potrzebuję zrobić dwie rzeczy: Zdiagnozować problem Ograniczyć straty Diagnostyka problemu: skrypt w momencie detekcji problemu (wysoki load, MySQL niedostępny, wchodzenie systemu w swap itp) zapisuje stan systemu który może być przydatny do diagnostyki do pliku. Ograniczenie strat (braku dostępu do systemu): automatyczny restart usług po pobraniu danych. Typowo piszę mały dedykowany skrypt w bashu-u i umieszczam go w cronie (np. co 5 minut). Wtedy maks. czas niedostępności systemu ograniczam do 5 minut a sobie zostawiam możliwość późniejszej analizy co się stało i finalnego naprawienia błędu. Prosty przykład: automatyczne ubijalnie procesów FastCGI którym wycieka pamięć:

Nie wspomniałeś, że Twój system siedzi na VPS-ie (a zapewne tak jest). "CPU usage - by week" wskazuje, że coś złego dzieje się z hostem. Procesy czekają na normalny dostęp do CPU i go nie dostają - stąd duży load. Dostępny procesor znacznie się zmniejsza. Proponuję kontakt z dostawcą VPS-a (hitme jak widzę), jeśli to nie pomoże zmiana na inną firmę. Nie znam szczegółów implementacji OpenVZ, może jacyś specjaliści się wypowiedzą na ten temat (co może aż w takim stopniu blokować CPU). Korekta: oglądałem czas restartu maszyny, stąd błedne wnioski. Ewidentnie Apache ssie CPU. Brakuje wykresu aktywności sieci (czy przyczyna jest zewnętrzna). Być może jest to zapętlenie w skrypcie PHP. Proponuję znacznie zmniejszyć timeout i wprowadzić watchdoga który przy wysokim load automatycznie zarejestruje stan systemu (lsof, ps itp) i zrestartuje apache. To powinno pomóc zdiagnozować problem.

To jest po części prawda, ale warto wspomnieć, że OpenVZ nakłada limity na pamięć wirtualną (VSZ) podczas gdy Xen na rezydentną (RSZ). Domyślny rozmiar stosu na Linuksie to 8 MB. Uruchomienie jednej aplikacji z 10 wątkami (np. wielowątkowy Apache) natychmiast zabiera minimum 80 MB przy OpenVZ. Przy Xen będzie to znacznie mniej (zwykle aplikacja zużywają tylko część zaalokowanego stosu i sterty). Z tego włąśnie powodu do Javy zalecany jest Xen (wiele wątków, dużo zaalokowanej i często nieużywanej sterty). Moje doświadczenia w zbijaniu zużycia pamięci w środowiskach OpenVZ/Debian.

Właśne zauważyłem, że wynajmowany VPS w Vaserve.co.uk przestał wpuszczać mnie po SSH (dostaję "Connection closed by"). Maszyna wirtualna zachowała swój klucz, ale nie rozpoznaje już klucza "gospodarza". Oznacza to poważne kłopoty na hoście. Jak znalazłem wszystkie marki VaServe zostały zaatakowane (cheapvps, a2b2 i fsckvps). Podejrzenia padają na świeże dziury w oprogramowaniu HyperVM. UPDATE: cytat z WHT: We will be placing details on vaserv.com and (http://66.71.245.2/~vaservc/) if DNS hasn't updated. At approx 7pm GMT VASERV HyperVM was hacked and it appears that all nodes have some level of damage. We are currently working on the situation and will be putting updates here. Currently we have no ETA on this

To jest wynik próby otwarcia strony z supportem Vaserv (wczoraj jeszcze działała): Jak widzę to jeszcze nie koniec kłopotów (kolejne włamanie?).

Maszyna wirtualna którą wynajmowałem w CheapVPS służyła jako jeden z pomocniczych węzłów monitorujących dla site-uptime.net. Na podstawie komunikatu ze strony statusu Vaserv wnioskuję że została przez napastnika skutecznie zaorana. Na szczęście mam automatyczny dzienny backup, więc odtworzę ją jak tylko odzyskam dostęp do konta. Po zakończeniu opłaconego okresu zamierzam przerzucić się do innego dostawcy. Przed katastrofą Vaserv też nie sprawiał dobrego wrażenia (powracające problemy z wydajnością IO).

Pomiary które podałem przeprowadzone są przy użyciu http://site-uptime.net. Mierzę tą usługą dostępność i parametry wszystkich serwerów z których korzystam.

Jeśli znasz się na administracji serwerem polcecam VPS w linode.com. Oto pomiary jednej ze stron u mojego klienta siedzącej w linode (trzeci miesiąc). Wykres prawie wzorowy, transfer tani (USA). Jeśli zwykły hosting, polecam Kei.pl, statystyki pokazują co prawda dużo "szpilek" ~2s w ciągu dnia, ale poza tym dostępność bardzo dobra (i polski admin jest 24h pod telefonem).

Poniżej e-mail z newslettera, wygląda groźnie (chodzi o serwis http://www.webhostingtalk.com/): Ciekawe, że specjaliści od hostingu dopuścili do włamania do swojej infrastruktury.