Dariusz Cieślak

W ramach przygotowania do migracji testuję kilku dostawców VPS-ów z Europy. Dziś na warsztat trafił OVH w wersji "entry" (opcja "Classic"). http://blog.aplikacja.info/2014/02/ovh-vps-classic-review/ Opis jest po angielsku, ale mam nadzieję, że to nie sprawi kłopotu. Za 3 miesiące podam wnioski z analizy stabilnościowej (mierzę czasy odpowiedzi ze skryptu używającego bazy danych). Potencjalne problemy z wydajnością (dysk / CPU / sieć) w dłuższym okresie powinny wyjść.

BTW. Panel OVH to taka straszliwa fuszerka (od strony używalności), że sam się czasami zastanawiam dlaczego jeszcze nie zmieniłem tego operatora (usiłując w kilkunastu podejścjach znaleźć jakąś opcję w menu). Być może ceny mają w porządku, ale nic nie zrobić z tym paskudztwem przez tyle lat ... szkoda gadać.

To co podałeś wygląda najzupełniej poprawnie. Brakuje pomiaru z momentu awarii. 1. Uruchom vmstat w tle, wynik przekieruj do systemu plików, poczekaj na awarię i po reboot obejrzyj wyniki. Na moje oko pojawi Ci się aktywność w kolumnie "so" (swap / zapis) - przyczyna wysokiego IO. Wzrośnie też kolejka "b" - procesy w stanie "D" czekające na I/O zablokowane przez swap 2. Jeśli (1) potwierdzone, to monitoruj RSS procesów j.w. (np. z interwałem 1s), żeby namierzyć proces który zaczyna "puchnąć". Przykład: $ ps xav | awk '{print $8, $10}' | sort -n | tail -1 410188 /usr/lib/firefox/firefox Na moim laptopie najwięcej RSS (~400MB) zjada klient protokołu HTTP. Dalej to już analiza na poziomie aplikacji, co może być trudne jeśli nie masz kodu źródłowego. Inna możliwa przyczyna problemów z I/O to inny VM na tej samej maszynie który nadużywa dysku + amatorski hosting VPS który nie może sobie poradzić z priorytetami I/O dla poszczególnych maszyn wirtualnych lub problem techniczny z dyskiem. Rozpoznanie: wysoki "B" (długa kolejka do I/O) + niskie wskaźniki bloków IN/OUT w Twojej maszynie wirtualnej (brak lokalnych winnych).

Według mnie używanie ramdysku w momencie kiedy kernel efektywnie używa całej dostępnej pamięci RAM na potrzeby buforów do dysku to nieporozumienie. Można łatwo sprawdzić czy rzeczywiście dostęp do dysku jest wąskim gardłem poprzez polecenie vmstat: Tu widać duże zużycie IO (w większości czytanie): $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 1 265984 118680 404636 857096 1 1 77 73 89 29 11 3 81 5 2 0 265984 116936 405320 857316 0 0 676 228 664 1246 2 4 50 45 0 1 265984 115696 406008 857136 0 0 688 0 614 1163 3 3 48 46 0 1 265984 118672 406620 857160 0 0 600 1656 625 1104 4 3 47 47 0 1 265984 124624 407368 849100 0 0 748 0 609 1237 3 3 48 46 0 1 265984 101684 408168 869588 0 0 800 0 813 2643 17 9 36 37 0 1 265984 99204 408896 870020 0 0 728 0 667 1272 5 4 46 46 A tu typowe CPU user space: $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 272564 52356 454708 880848 1 1 78 73 89 32 11 3 81 5 2 0 272564 58432 454716 876416 0 0 0 132 468 527 53 1 46 0 1 0 272564 58432 454716 876188 0 0 0 0 566 488 53 1 46 0 1 0 272564 57936 454716 876140 0 0 0 0 767 636 54 1 46 0 1 0 272564 57564 454724 876132 0 0 0 20 1181 718 53 2 45 0 Jaka sutuacja jest u Ciebie - ciężko powiedzieć. Pomiar w pierwszej kolejności - potem próby naprawienia problemu.

mod_python oznacza wspólny proces (i ten sam włąściciel) dla wszystkich instancji Pythona. Proponuję rozejrzeć się raczej za mod_fcgi + suexec (Twoje procesy z Twoim UID i odrębnymi uprawnieniami). Jeśli serwer daje tylko CGI (suexec), ale zezwala na długo działające procesy można zastosować bridge cgi-fcgi w języku C który komunikuje się z długo działającym procesem. Wtedy narzut per żądanie jest tylko na fork+exec procesu w języku C ("ciężki interpreter" jest w pamięci na stałe).

Ciekawostka: czas odpowiedzi forum wht (<1s) znacząco spadł w drugiej połowie 2012r (poniżej 10% odpowiedzi z tym czasem). Teraz już jest lepiej. Ciekaw jestem czy to zmiana maszyny czy coś od strony oprogramowania. Pełen raport.

Wczoraj od 17-tej do północy nie mogłem zalogować się na WHT. Był jakiś problem z DNS ("Name or service not known"). Monitor pokazuje mi "brak dostępu": http://s2.site-uptime.net/su.cgi/report?publicKey=6fxw8735zfi9tljcht9jboo1rwfuc9ks Czy ktoś wie co się stało?

Obejrzałem skrypty w tym (reanimowanym) wątku i doszedłem do wniosku, że można zapisać to samo, ale dużo bardziej kompaktowo (korzystając z faktu, że stdout skryptu odpalonego z crona idzie na e-mail właściciela crontaba): 5-minutowy load serwera przekracza wartość 4: */5 * * * * cat /proc/loadavg | awk '$2 > 4 { print "High 5-minute load", $2 }' Zużycie miejsca na dysku większe niż 90%: 00 21 * * * df | awk '/^\// && $5 > 90 { print $0 }' I tak, dalej, zastosowania można łatwo sobie wymyśleć. Odnośnie "w PLAY się nie da": można wykupić komercyjną bramkę SMS, która ma zwykle interfejs po HTTP/GET, co pozwoli pewnie wysyłać do siebie komunikaty SMS niezależnie od docelowej sieci (nie będę tu reklamował konkretnego dostawcy, można ich wyszukać w Google).

Przelew może iść długo jeśli jest zlecony np. na poczcie. Proponuję skontaktować się telefonicznie z firmą, żeby wyjaśnić przyczynę braku zaksięgowania płatności.

Nie powinien, FTP korzysta z innego portu. Proponuję sprawdzić czy port 22 jest na maszynie otwarty:

Oto fragment komentarza z portalu vat.pl z tej sprawie: Trochę zagmatwane, ale obrazuje sytuację.

To też import usług (zakładam, że chodzi o usługi), procedura podobna jak zakup usług z UE - czyli przez fakturę wewnętrzną.

[quote name=lolek ' date='13 May 2010 - 08:25' timestamp='1273731956' post='204673] Jak mogę rozliczyć się z Fiskusem na podstawie faktury niemieckiej ??. Zakładam, że dostałeś fakturę bez VAT z informacją, że odbiorca powinien rozliczyć VAT u siebie (usługi). Procedura jest następująca: Wystawisz fakturę wewnętrzną w której doliczasz polski VAT (kurs NBP z dnia poprzedzającego wystawienie faktury) FW do rejestru zakupowego VAT i do KPiR (tu oczywiście netto) Następnie rozliczasz róźnice kursowe w KPiR (sumarycznie koszt w KPiR będzie równy zapłaconej kwocie) Naliczony VAT trafi do kolumny "import usług" przy rozliczeniu VAT, tym samym należności VAT wobec polskiego fiskusa na poczet tej faktury = 0 (czyżby "Hetzner" :-) ?)

Proponuję zamiast założenia że system nie będzie migrowany przygotować (i przetestować) procedurę backupu i (pół)automatycznej migracji na nową platformę. Współdzielony hosting zawsze wyłączy Twój serwis jeśli będziesz nadużywał zasobów (może dać Ci co najwyżej wcześniej ostrzeżenie).

Polecam Linode.com (najmniejsza opcja 20 USD/mo). Używam sam i zamawiam pod systemy dla swoich klientów.