Portek

A co to za problem zarejestrować swoją własną licencje NPL? http://npl.teamspeakusa.com/ts3npl.php

Informacji w sieci n/t tego błędu jest w sieci multum. Z autopsji wiem że działa 99.9% z nich, kwestia chęci wyszukania jednego poradnika z pierdyliona innych... http://sleepycode.com/2010/12/convert-ts3-from-sqlite-to-mysql-database/ http://ubuntuforums.org/showthread.php?t=1877721 https://freevps.us/printthread.php?tid=4251 Każde z nich poprawnie wykonane spowoduje odpalenie serwera.

Witajcie, pytanie do Was, bardziej doświadczonych użytkowników i administratorów. Mam "drobny" problem z moim VPS'em, wczoraj wieczorem zaliczył defekt, partycja która była mu przydzielona, nagle dziwnym trafem została oznaczona jako "tylko do odczytu", wszystkie usługi zaczęły wariować, w efekcie czego portal i forum padło. W ruch poszło polecenie fsck, partycja została sprawdzona, naprawiona i w celu wprowadzenia zmian miałem wykonać reboot. Tutaj niestety pies pogrzebany, system nie wstaje, nie widzi partycji która nadal gdzieś tam jest, zamiast systemu widzę magiczny komunikat: Target filesystem doesn't have requested /sbin/init. No init found. Try passing init= bootarg. /bin/sh: can't access tty; job control turned off Jako szczęśliwy posiadacz tryby recovery, odpalam go i jeszcze raz, przy pomocy fsck próbuję reanimować partycje, wszystko wygląda okej, po raz kolejny sprawdzona, naprawiona ( /dev/sdb1: clean, 72091/1638400 files, 2458779/6553600 blocks ), reboot i? I nadal ten sam error. Dodam że po zamontowaniu partycji w trybie recovery mam do niej dostęp, pliki więc mogę skopiować, ale nie bardzo uśmiecha mi się ponowna instalacja i konfiguracja tego wszystkiego. Tutaj pojawia się owo wyżej wspomniane pytanie, czy istnieje opcja żeby partycje uratować i obejść się bez reinstalacji systemu? Dane mogę skopiować, tyle że chce rozwikłać zagadkę, dlaczego nagle z dnia na dzień partycja odmówiła posłuszeństwa - na serwerze nie byłem od dość dawna, ze względu prostego - wszystko działało i nie było najmniejszej potrzeby gdziekolwiek grzebać. OS: Debian 6 Firma: Sławny e24cloud Bok stara się pomóc jak może, tyle że obecnie zostałem zwiedziony magicznym "technicy sprawdzają".

Gdyby nie fakt że mam jeszcze kilkadziesiąt złociszy w portfelu to pewnie bym tak zrobił, jednak od dłuższego czasu - właściwie od początku współpracy do sławnego padu macierzy, wszystko było okej, więc jeszcze ich nie przekreślam :-) Na plus jest support, który w 10min od zgłoszenia "coś" próbował zrobić. No nic Panowie, dziękuję za pomoc i rady. Odzyskałem sporą część danych, z tego co mam odbuduję swoje strony, niestety do tej pory nie dostałem wiadomości z BOK'u co było powodem tego błędu.

Dokładnie, tyle że jak przyjrzeć się pliką to część z nich wyparowała w kosmos. Folder użytkownika X jest, ale użytkownika Y zniknął. Generalnie wygląda to śmiesznie, nie mam ochoty dłużej czekać na support, sam jestem bezradny. Zrobię kopię tego co mi zostało i postawię usługi na nowo.

Partycje mam jedną, montowaną właśnie pod /dev/sdb1. W prawdzie revocery widzi jeszcze sdb2 tyle że to swap, i sda w którym montowany jest obraz systemu recovery. Raczej wątpię że padły im znów dyski czy ram, u mnie to wygląda tak że po naprawieniu via fsck nadal nie działa - mimo że powinno.

https://github.com/Austinb/GameQ - niezależna kontynuacja GameQ

No bo miało być inaczej, a napisałem jeszcze inaczej... fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; na: fastcgi_param SCRIPT_FILENAME /var/www/ghst.pl/web$fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_script_name; na: fastcgi_param SCRIPT_FILENAME /var/www/ghst.pl/web$fastcgi_script_name; Bo jak zadziała PHP to zobaczysz magiczne "File no found" Pewny jesteś że FPM pracuje na porcie 9011?

Maszyny maszynami, ale jakość kuleje czasami. Jeszcze z 2mc temu korzystałem z waszych usługi i po problemach z konfiguracją (po waszej stronie, wedle supportu "coś" się przestawiło) musiałem się czym prędzej wynosić. Na krytyczne zgłoszenie dotyczące powtarzającego się błędu, odpowiedź dostałem bagatela po tygodniu czasu! Coś chyba jest jednak nie tak? Nie jestem jedynym klientem, nie mam supportu premium, ale support 24/7/365 to jakiś żart :-)

Witajcie! Mam taki dość denerwujący problem z jednym z VPS-ów (XEN HVM) - w przeciągu nie całych dwóch godzin serwer zaliczył różnicę czasu rzędu 14min. Ciągle nie mogę sobie z tym poradzić, strefa czasowa jest okej, a nadal czas zwyczajnie na świecie kuleje. Nie satysfakcjonuje mnie też za bardzo rozwiązanie z crontabem, raz na godzinę, bo to zwyczajnie bez sensu, a dane są nie spójne. Istnieje jakaś opcja żeby sobie z tym poradzić? System operacyjny Debian 6 (64bit).

Każdy jest alfą i omegą, tak ja też... Gdybym cokolwiek znalazł, to pewnie bym nie pisał, ale widzę że niektórych razi to w oczy... Dostęp do serwera mam tylko Ja, nikt czasu nie zmienia, ani nic - bynajmniej logi o tym milczą.

Szukam rozwiązania problemu, a nie połowicznej naprawy.

Zakładając że w ciągu 2h zegar cofa się o 14min, to w 24h będzie to już 168min (ponad 2,5h) więc jest to żadne wyjście. Dlatego też piszę tego posta, postaram się jeszcze raz skontaktować z dostawcą. Zastanawiałem się po prostu czy nie jest to wina gdzieś po stronie wirtualizacji.

Wykonuję aktualizację czasu via ntpdate. Według dostawcy inni klienci takich problemów nie mają.

Witajcie! Szukam VPS'a który był by zamiennikiem VolumeDrive pod kątem prędkości rzeczywistego dostępnego pasma. Na serwerze pracuje de facto obecnie tylko nginx, który obsługuje download statycznych plików (docelowo kilka mało wymagających aplikacji). Wiem że to VPS z dzielonym łączem i cudów wymagać nie mogę, ale gdy będąc jedynym klientem pobierającym plik i nie mogę osiągnąć nawet 100KB/s to niestety jak dla mnie za mało. Co potrzebuję? 30-50GB na dysku 1-2TB Dość "normalne*" pasmo 256-512 RAM Lokalizacja właściwie obojętna, USA gdzie czas odpowiedzi sięga 160ms dawał radę. Co do ceny to oczywiście jak najtaniej, nie wymagam nie wiadomo czego, statyczny download + kilka naprawdę mało wymagających aplikacji. * Pisząc normalne mam na myśli te 2-5MB/s które rzeczywiście serwer osiągnąć może.

Taką to odpowiedź dostałem na zapytanie co do pada.

s16 ma wzloty i upadki, w przeciągu 14 dni drugi downtime, Dziś po godzinie wstało i odpukać na razie działa.

@UP szybszy, do kasacji. Powinno być okej: rewrite ^/profile_show,(.*),(.*),nb.html?$ /index.php?act=profile_show&user=$1&step=$2&no_body=1 last; rewrite ^/profile_show,(.*)-(.*),(.*).html?$ /index.php?act=profile_show&user=$1&step=$3 last; rewrite ^/profile_show,(.*)-(.*).html?$ /index.php?act=profile_show&user=$1 last; # Other # rewrite ^/(.*),(.*),(.*),(.*),nb.html?$ /index.php?act=$1&step=$2&add=$3&add2=$4&no_body=1 last; rewrite ^/(.*),(.*),(.*),nb.html?$ /index.php?act=$1&step=$2&add=$3&no_body=1 last; rewrite ^/(.*),(.*),nb.html?$ /index.php?act=$1&step=$2&no_body=1 last; rewrite ^/(.*),(.*),(.*).html?$ /index.php?act=$1&step=$2&add=$3 last; rewrite ^/(.*),(.*).html?$ /index.php?act=$1&step=$2 last; rewrite ^/(.*).html?$ /index.php?act=$1 last;

Powiem tak, nie zależy mi na ogromnej mocy, czy Polskiej lokalizacji. Ma być do serwer do przetrzymywania i udostępniania (legalnych) statycznych plików. Momentem może być tak że nikt nie pobiera plików, a za 10min klientów do pliku 5-10MB będzie 60. Obecnie najciekawiej prezentuje się DMEHosting.

Mój na maszynie 16 odpowiada bez problemów.

Tak sobie siedzę i walczę z silnikiem www (nginx 1.0.8, jak również w wersji 1.1.5), a właściwie to z PHP (5.3.8-1~dotdeb.2) i MySQL (Ver 14.14 Distrib 5.1.49). Rozchodzi się o to iż wczoraj migrowałem od jednego dostawcy usług do drugiego. Różnic jeśli chodzi o konfigurację de facto brak - 2GHz procesor, 512MB RAM [1GB BURST w OpenVZ] - w godzinach "szczytu" nie zjadałem nawet 70% zasobów, różnica jest w wirtualizacji: migrowałem z OpenVZ na XEN HVM i od tego czasu zaczęły się cyrki. PHP - zarówno FPM i fastcgi, nie może sobie poradzić z wypluciem forum (IP.Board), połączeń do hosta 30, de facto cała pamięć zjedzona (a 150MB w cache). Pracuję już troszkę na nginxie w konfiguracji z fastcgi i nigdy nie miałem problemów z wydajnością tego zestawu, spokojnie obsługiwał bez zająknięcia 150 użytkowników online, a teraz przy 15 (kolejne 15 to statyczne strony HTML) nie daje sobie rady. Jakieś pomysły? Chciałem wybrać mniejsze zło i przejść na gwarantowane zasoby i obecnie nad tym lekko mówiąc ubolewam. Próbowałem zastosowań memcached i APC, efekty? Brak - choć w sumie momentami dało się zauważyć przyśpieszoną pracę, ale równie szybko ten efekt znikał. Śmieszy mnie to ciut, bo zrozumiał bym że walnąłem bubla w konfiguracji (aczkolwiek testowałem starą, efekt identyczny) i wszystko działało jak krew z nosa, tutaj są momenty że działa doskonale, a później pociąć się można. Czy może to być wina systemu? Wcześniej Debian 5 (32Bit), obecnie Debian 6 (64Bit) - jeśli może to być problem to pokuszę się o reinstalację systemu z obrazu. PS. Celowo nie podaję nazw firm, bo nikogo nie chcę oczerniać i nie będę tego robił. #Edit Efekt po dłuższej chwili działania? Load na poziomie 5-5,5, wolnej pamięci 60MB (wraz z cache).

W skrócie zasoby gwarantowane nie istnieją? :-) Dobra, więcej i tak chyba nie wywalczymy, zobaczę jak to się będzie zachowywać, ew. wrócę na OpenVZ - trudno się mówi.

Wedle zapewnień firmy zostałem umieszczony jako jeden z pierwszych klientów na nowej maszynie. Takie trochę "nie chwal dnia przed zachodem słońca" mnie spotkało właśnie. Obciążenie identyczne, a za nic php nie radzi sobie - najlepsze jest to że dzieje się to w godzinach mocno popołudniowych, a w godzinach szczytu działa okej

Tak się zastanawiam i nie wiem jak wytłumaczyć dziwny fakt: wczoraj podałem zarówno dane z `vmstat` i `free` - efekt? Nie działało de facto wcale. Dziś? http://wklej.org/hash/9f28f856f11/ Jak racjonalnie wyjaśnić, że przy tych samych zasobach wczoraj nie działało, a dziś działa tak jak powinno?