beliq

a nie możesz zwyczajnie zmienić IP głównego na to z puli "fail-over"? adres będzie nowy, a serwer zostanie jak był

Nephax, Gdańsk, ruch leci via NASK i Telię wprost do UK, 16 hopów, ping 43 ms

standardowy TTL dla wpisów NS wynosi 24 godziny, oczywiście możesz to sobie zmniejszyć tymczasowo przed przeprowadzką...

no, niestety wiele produktów korzysta z takiej zasady licencjonowania, niby masz wersję dożywotnią, ale rok rocznie musisz zapłacić za aktualizację do najnowszej dostępnej wersji...

jakie koszta masz na myśli? wysyłki? księgowe? a może chcesz otrzymać zwrot opłaty instalacyjnej za serwer?

daj innym zarobić!

2K USD miesięcznie conajmniej, faktycznie, za tą kasę już można już coś budować, aczkolwiek ja bym przyjął te 2% jako wartość graniczną

to swoją drogą aczkolwiek to zliczanie tych wszystkich limitów jak to w nazwa.pl robią wcale nie jest takie obojętne dla obciążenia platformy jak się wydaje, na szczęście większość z nich obslugują routery i zapory

Znasz odpowiedź Przecież te 2% to taka sama papka marketingowa jak te TB-ty powierzchni i transferu, absolutnie nie do wykorzystania, weź cenę takiego Della PE z dwoma Quadami i 16 GB pamięci ECC, podziel przez 10$ ( czy ile tam konto nie kosztuje ), a zobaczysz ile kont trzeba wepchnąć żeby być chociaż na przysłowiowe "zero" kolejny dreamhost i tyle

Z jednej strony tak, z punktu widzenia administratora jest to najzwyklejsza w świecie "oszczędność czasu".

no dobra, ale te Xeony są single, dual czy quad core? ( )

Po pierwsze, to ja bym radził zmienić ( zmniejszyć ) na 48 godzin przed przeprowadzką TTL wszystkich wpisów DNS na serwerze A dla domeny abc.com. Na serwerze B możesz korzystać z własnych DNSów z małym ale, jeśli TLD jest nasze rodzime, musisz zarejestrować hosty w rejestrze NASKu.

Zrobiłem sobie VPSa z przydziałem 256 MB pamięci. Instalacja z paczek Debiana nie wspiera "security manager", tak więc należy w /etc/default/tomcat5.5 wyłączyć tę opcję. Jak już się z tym uporamy okazuje się, że przy standardowej konfiguracji 256 MB pamięci to za mało i Tomcat nie może stworzyć wszystkich potrzebnych sobie procesów. Faktycznie licznik użycia zasobów dla maszyn wirtualnych wskazuje próby nadalokacji przydziałów. Przy 384 MB problem ten nie występuje, wszystko uruchamia się poprawnie. Oprócz tego wspomniany switch "xm", na ile mnie pamięć nie myli, wskazuje nie tyle co ile daemon ma zużyć na starcie, a jakiego limitu ma przy zdefiniowanej mu w plikach konfiguracyjnych funkcjonalności ma nie przekroczyć, stąd obniżanie jego wartości bez końca nie ma sensu. /var/log/tomcat5.5/catalina-$data.log

Czy ja gdziekolwiek napisałem, że źle zrobiłeś? Stwierdziłem tylko fakt, że ich polecałeś. NVU jest jaki jest, ale hosting sam w sobie sprawuje się chyba dobrze sądząc po braku informacji dt. "padów", więc żałować chyba specjalnie nie ma czego.

Skoro już takim tonem piszemy, to powiem tak: Pisząc na tym forum czy Ci się to podoba czy też nie zobligowany jesteś "z automatu" do podporządkowania się zwyczajom tu panującym ( jest nawet pewne stare przysłowie to opisujące ), także tym niepisanym... Przez 30 dni miałeś FH w swojej stopce, więc w obliczu opinii publicznej przez te 30 dni ich polecałeś... tyle.

BOSS po mimo całej sympatii muszę się zgodzić z kaczym, umieszczenie linku do firmy hostingowej w stopce staje się na tym forum (i wielu innych) z automatu poleceniem...

dzięki za wiarę we mnie niestety to nie jest jeden z tych problemów, które zdalnie w mig da się ocenić na podstawie kilku informacji na krzyż i na tacy podać rozwiązanie... odnośnie samego Tomcat'a podejrzewam, że zwyczajnie w zmiennych środowiskowych brakuje Ci ścieżki do Javy, tudzież czegoś w tym "w stylu" chętnie bym to teraz zdebugował w ramach przypomnienia, ale nie mam czasu, tym bardziej, że nie wiem jakie kroki poczyniłeś, co zmieniałeś itd. najlepiej pogoogluj za jakąś frazą: howto debian vps tomcat znajdź howto, wpisy na forach i dopasuj do swojej sytuacji

dwa dni mnie raptem nie było, a tu taki ubaw na forum... dlaczego nikt mi nie wysłał SMSa?

na tacy rozwiązania nie dostaniesz, ale dam Ci wskazówkę: za rysowanie wykresów nie odpowiada bezpośrednio munin, a mrtg każdy tworzony przez ten program wykres musi mieć swoją z góry zdefiniowaną konfigurację - poszukaj tego pliku, bo gdzieś jest; to co Ciebie interesuje w tym wypadku to info dt. ilości próbek na podstawie których mają być tworzone wykresy jeśli próbek brak - automatycznie powstają puste pola w ich miejsce, stąd też musisz zwyczajnie zmniejszyć częstotliwość z jaką ten program spodziewa się danych wejściowych...

jasne, nie zapomnij tylko o wyłączeniu usług SQL, gdyż utracisz spójność baz robiąc nagły remount read-only na działającym wcześniej produkcyjnie serwerze Wszystko co napisałeś, a nawet o wiele więcej, da się zrobić samym rsync'iem pod jednym tylko warunkiem, że występuje zgodność architektury systemu - tj. 32 bit -> 32 bit i 64 -> 64. To jakie dyski, kontrolery, procesory były/są nie ma znaczenia, bo wystarczy co najwyżej zbudować monolityczny kernel ze wszystkim "jak leci", albo dopisać odpowiednie moduły do uruchomienia wraz z systemem.

rfc zapewne głosi co innego, nie mniej jednak prawda jest taka, iż bazy danych powinieneś archiwizować robiąc z nich wcześniej dump, resztę możesz kopiować jak leci...

ehkm, niestety nie jedyna rzecz jaka Cię może przed tym uchronić, notabene połowicznie, to opcja fallback boot loadera grub... jej użycie umożliwi automatycznie załadowanie poprzedniego ( w tym wypadku należy rozumieć: ostatniego sprawnego ) kernel'a po następnym reboot'ie w innym wypadku wymagane będzie użycie trybu rescue i edycja pliku grub.conf w celu zmiany default'owego kernel'a

mają pingi tak wspaniałe, że jak podczas gry próbujesz komuś zrobić tzw. "head shot'a" to przeciwnik pada nim kula doleci... ( )

na bank, bo do USA przepchanie takiej ilości danych trwałoby całe "wieki"...

z tego co pamiętam to niestety nie