pleple

A czy Kei nie ma serwerowni w Krakowie przypadkiem? // EDIT Sisco jest z Wrocławia. Na forum jest trochę opinii o tej firmie.

VHCS.. Załóż sobie konto na www.cba.pl (hosting darmowy) to zobaczysz jak to wygląda od strony użytkownika (w dość wiekowej i pewnie nieźle dziurawej wersji:))

Dodam tylko iż ja mam zarejestrowaną swoją eKartę w Paypalu więc jest ona akceptowana.

To zależy od aplikacji, nie od samego wine, ile RAMu czy procesora jest zużywane.

Jak się chwilę zastanowić to nie jest to takie niezrozumiałe. Podawanie publicznie takich szczegółowych informacji nie jest raczej dobrym pomysłem nawet przy sprzedaży firmy. Podejrzewam, że każdy z forumowiczów posiadający podobne usługi przyzna mi racje, że takimi informacjami lepiej nie chwalić się na wszystkie strony. Duże zyski to kwestia bardzo względna, dla niektórych to kilka tyś złotych miesięcznie, dla innych kilkanaście. Takie firmy to często działalność jednoosobowa (tzn. z użyciem outsourcingu) i właściciel poświęca jej większość swojego czasu. W takim wypadku taka firma to tak na prawdę on sam i kiedy z jakiegoś powodu musi zająć się innymi sprawami to musi pozbyć się firmy. Inna sprawa jest taka, że znam ludzi którzy zarabiają na sprzedaży różnego rodzaju serwisów usługowych (w tym darmowych hostingów) za granicą. Po prostu stawia taki serwis, przez pare miesięcy go rozkręca a potem sprzedaje za 4-5 razy tyle ile ten serwis przynosi dochodów miesięcznie i zabiera się za następny.

Tak, karta Inteligo działa bardzo dobrze w systemie PayPal.

Karta Visa Electron w Inteligo nie jest wypukła z tego co pamiętam a Paypal ją akceptuje. Myślę, że właśnie przez takie wyjątki pojawia się tyle wątpliwości..

Reinstalacji? W ten sposób się nic nie nauczysz...

Ale co podejrzanego chciałeś zobaczyć hexeditem? Myślisz, że autor by trzymał jakiegoś stringa w stylu "to jest wirus" wewnątrz programu?

Że co sprawdziłeś i jest błędne?!

Pewnie nie jest to wirus ale jest to trojan (z definicji - udaje program do przechwytywania domen a w praktyce kradnie hasła), który jednak nie działa. Reszta Twojej argumentacji jest zupełnie błędna. Nie rozumiesz jak działają wirusy i programy antywirusowe, w tym jest Twój problem.

Nie musi otwierać portu. Może wcale nie jest źle napisany tylko specjalnie "wywalił" się na koniec żebyś tak właśnie myślał a wcześniej wyprodukował sobie usługę, która jest uruchomiona w tle, ładnie się maskuje i czeka na polecenia albo zbiera dane do wysłania. Wątpię aby tak było ale jest to technicznie możliwe i nie aż tak trudne do osiągnięcia.

Piszesz to tak jakby dyski padały raz na parę dni a tak nie jest! Owszem odbudowa macierzy dysków SATA 500GB trwa kilkanaście godzin ale tak realnie patrząc, jak często może się zdarzać? Dzisiejsze dyski SATA mają często gwarancję na 36 miesięcy co oznacza, że średnia bezawaryjność ich pracy musi być znacznie większa (bo inaczej nie opłacałoby się to producentowi). Mając więc macierz 4 dysków SATA możemy się spodziewać padu jednego z dysków raz na rok, raczej nie częściej. Kilkanaście godzin zmniejszonej szybkości operacji dyskowych w roku to raczej nie jest jakiś problem.. Poza tym jest jeszcze live migration dzięki któremu można łatwo przenieść połowę VPSów na inny serwer na czas odbudowy macierzy i wtedy ta odbudowa może być w ogóle nie zauważalna

Jest to procent czego? Ilości zapytań czy czasu spędzonego na danych zapytaniach? Masz setki tysięcy hitów dziennie czy po prostu do bani skrypt? Raczej nad tym bym się zastanowił bardziej.. Nie obraź się ale to bzdura (tak, zauważyłem ten "języczek" ale uważam iż autor wątku potrzebuje raczej konkretnych opinii niż bezsensownych wypowiedzi). Zasadniczo load sam w sobie nie daje wyznacznika tego czy system jest przeciążony czy też nie. Fakt jest jednak taki iż optymalny load jest w przybliżeniu równy ilości dostępnych procesorów (czy rdzeni). Oznacza to iż procesy zasadniczo nie kolejkują się w oczekiwaniu na zasoby procesora. W żadnym wypadku jednak load wyższy niż to nie jest problemem o ile widoczna responsywność aplikacji nie jest zaburzona. Za zwyczaj takie opóźnienia pojawiają się jednak kiedy load zaczyna wzrastać powyżej 3 (przy jednym procesorze). Prościej byłoby pewnie przejść na lżejsze MPM (np. worker) w Apache co wpłynęłoby bardzo podobnie na wydajność jak zmiana samego serwera (ponieważ większość z tych serwerów szybszych niż Apache po prostu używa domyślnie wątków podczas kiedy Apache nadal (dla kompatybilności z kiepskimi modułami jak mod_php) używa MPM prefork. Jednak to czy różnica będzie zauważalna zależy głównie od charakteru stron serwowanych przez dany serwer.

Polecam http://www.google.pl/translate_t, oto jak przetłumaczył informacje na temat backupu: "Backup & monitoring To the protection from overrun, in each case two Backups can be at the same time stored. The Backup and possible Restores are started over the Virtuozzo power panel. The Backup Traffic is inclusive. In order losses fast recognize and to repair to be able, are the monitoring of your server important. Monitoring M 2,0 examines every 30 minutes up to 10 services and informs you in case of emergency by SMS, fax or E-Mail." Co do wydajności dysków... Z tego co oni piszą, na każdym serwerze może być max 15 VPSów. W zależności od tego który pakiet wybierzesz, do hostowania systemu użyte są komputery klasy odpowienio celeron, penium 4, pentium D lub Xeon. Są to jednak zawsze markowe maszyny Dell Poweredge Nie podają danych dotyczących dysków ale na podstawie klasy użytego sprzętu można wysnuć już jakieś wnioski. Prawdopodobnie używają RAID1, dla najmocniejszych VPSów prawie na pewno dysków SAS (to jednak tylko moje przypuszczenia wysnute z konfiguracji). Jeśli chodzi o wydajność w porównaniu do dedyka.. Na dedyku masz własne I/O a na VPS może sporo zależeć od "sąsiadów". Systemy wirtualizacji posiadają możliwości definiowania priorytetów I/O ale nie da się tego podzielić po równo jak np CPU czy pamięć (z gwarancją).

Po części się tym zgadzam ale nie w 100%. Windows Vista został już pod tym względem trochę poprawiony ale aż do Windowsa XP zabezpieczenie wewnętrzne tego systemu przed zepsuciem systemu przez złośliwie (lub wadliwie działającą) aplikację były prawie zerowe. Ponadto bardzo duża różnorodność dystrybucji Linuksa utrudnia napisanie skutecznej złośliwej aplikacji. Niemniej jednak niezależnie od tego jakiego używa się systemu operacyjnego, uruchamianie każdej aplikacji z Internetu bez uprzedniego jej sprawdzenia może skutkować utratą danych lub kradzieżą. I to nigdy się nie zmieni.

AFAIK jesli VPS jest na Xen to nie ma limitów na ilość procesów. Po prostu nie bardzo da się takowe wprowadzić. Xen działa na innym poziomie abstrakcji, jest powyżej jądra i tak na prawdę nie wie co dzieje się w środku VPS. Można mu przydzielić RAM, powierzchnię dyskową, zasoby procesora itp. ale nie da się wpłynąć na inne szczegóły jak w przypadku wirtualizacji na poziomie systemu operacyjnego (jak OpenVZ/Virtuozzo, Linux-Vserver czy freevps).

Nie. Odczytywanie tej wartości jest na tyle proste, że raczej nie wpływa znacznie na samą wartość. Chodzi o to, że load liczony w 1 minucie jest podatny na "nagłe skoki". W związku z tym prawie zawsze jest znacznie wyższy niż ten liczony w dłuższym czasie a więc jest najmniej miarodajny. Load liczony w ciągu 15 min pokazuje pewien trend i nie jest tak podatny na chwilowe wahania. Nie chcę się zresztą powtarzać, więcej na temat load avarage napisałem dziś w tym poście: http://www.webhostingtalk.pl/index.php?s=&...ost&p=72987

O co mu chodzi? A o co Tobie chodzi? Load avarage jest na prawdę źle wyświetlany przez co mało obeznani admini (bez obrazy) zupełnie źle go interpretują. Bardziej interesująca jest zawsze ostatnia z 3 wyświetlanych liczb. Ona pokazuje trend uśredniony w dłuższym czasie. Masz go tylko nieco powyżej 1. Oznacza to, że kolejka uruchomionych procesów jest bliska 1. Czy to dużo? Widzę, że masz zespawnowanych sporo procesów apache, które w dodatku są nawet zajęte. Oznacza to, że prawdopodobnie masz MPM prefork i jakiś stały ruch na stronach WWW. Co jest więc dziwnego w Load Avarage dla 15 min na poziomie 1 w takim przypadku? A, no i nawet w samym TOP widać, że 2 procesy są uruchomione. Jak się dłużej przypatrzysz to okaże się, że pewnie przez większość czasu właśnie 2 procesy są odpalone przez co load avarage zbliża się do 2 w krótkim czasie.

Ja miałem .net i po prostu nie było do niej ŻADNEGO panelu.

Myślałem, że chodzi Ci o odpisywanie na jednego posta i wiele cytatów z tego jednego posta. Jeśli chcesz na raz odpowiedzieć na więcej tematów to musisz kliknąć przy każdym, na który chcesz odpowiadać, na przycisk "cytuj" w jego prawym dolnym rogu tak żeby zrobił się czerwony i posiadał minus a nie plus. Po tym klikasz na dole strony na "odpowiedz" i dostaniesz w oknie edycji cytaty wszystkich postów, które "mają minusa". Teraz możesz dodatkowo podzielić poszczególne cytaty na mniejsze itp. Nigdy nie próbowałem czy da się w ten sposób odpowiedzieć na posta z różnych stron w temacie..

Potwierdzam. Miałem u nich domenę i transfer zajął mi wiele dni (ponad tydzień). Na szczęście ja procedurę rozpocząłem wystarczająco wcześniej.

Dzielisz cytat na parę części, zaznaczasz sobie linijkę z tagiem quote , wklejasz w kilku miejscach gdzie zaczyna się kolejny cytat, tam gdzie się kończy wklejasz każdym razem tag /quote. Jakie znaczenie ma tu nick?

Zaznaczenie danego

Load avarage jest na prawdę mało miarodajnym parametrem. Ponieważ tak często pojawia się tutaj ten temat pozwolę sobie przybliżyć trochę sposób w jaki ten parametr jest liczony. W linuksie makro, które się tym zajmuje zdefiniowane jest w pliku nagłówkowym jądra (include/linux/sched.h): #define CALC_LOAD(load,exp,n) \ load *= exp; \ load += n*(FIXED_1-exp); \ load >>= FSHIFT Odpowiada to równianiu: load(t) = load(t - 1) exp + n (1 - exp) gdzie exp jest pewną stałą dla danego odcinka czasu (jest zdefiniowana jako e^(-5/60m), gdzie m jest parametrem oznaczającym czas dla którego mierzony jest load - 1,5,15 minut ) Ok, a tutaj mamy funkcję z pliku kernel/timer.c gdzie to makro jest wykorzystywane: /* * calc_load - given tick count, update the avenrun load estimates. * This is called while holding a write_lock on xtime_lock. */ static inline void calc_load(unsigned long ticks) { unsigned long active_tasks; /* fixed-point */ static int count = LOAD_FREQ; count -= ticks; if (unlikely(count < 0)) { active_tasks = count_active_tasks(); do { CALC_LOAD(avenrun[0], EXP_1, active_tasks); CALC_LOAD(avenrun[1], EXP_5, active_tasks); CALC_LOAD(avenrun[2], EXP_15, active_tasks); count += LOAD_FREQ; } while (count < 0); } } Jak więc widać, za n podstawiana jest wartość active_tasks, wyliczane przez funkcję zdefiniowaną w tym samym pliku: static unsigned long count_active_tasks(void) { return nr_active() * FIXED_1; } Żeby już nie zanudzać napiszę iż funkcja nr_active() jest zdefiniowana w pliku kernel/sched.c i sumuje ona wszystkie procesy działające oraz te "uninterruptible" na wszystkich aktywnych procesorach. Procesy uśpione, czekające na I/O itp. nie są liczone. KONKLUZJA: Load avarage jest parametrem uśrednionym w pewnych odcinkach czasu, z charakterystyką eksponencjalną (przy wzroście lub spadku), zależną od ilości działających w systemie procesów. Również ilość zapytań do bazy to żaden wyznacznik. Musisz zbadać jakie to zapytania. Prosty SELECT z indeksowanej tabeli może zająć nawet tysięczne części sekundy. 37 takich zapytań zajmie na prawdę mało czasu i przez ogromną większość czasu silnik bazy danych będzie się nudził. Źle zaprojektowane zapytania do bazy danych potrafią jednak trwać dużo dłużej, nawet kilkanaście sekund. Wtedy wykonanie takich 37 zapytań na sekundę jest nawet nie możliwe. Podsumowując - musisz raczej zbadać jakie zapytania są wykonywane i ile czasu zajmuje ich wykonanie. Może część z nich da się zoptymalizować a może nawet nie jest to potrzebne. Najprawdopodobniej jednak 37 zapytań na sekundę wykonanych na sprzęcie z małą ilością zasobów to dość sporo. To na jakiej maszynie jest nie jest tak istotne. Ważniejsze jest raczej to jak duża część zasobów jest przydzielona Tobie. Za zwyczaj na wyższym planie masz również więcej zasobów więc w takim wypadku odpowiedź będzie "raczej pomoże ale nie wiadomo jak bardzo".