huan

Nie wiem, czy inni też mają takie problemy, ale obecnie DotPay.pl zwleka prawie miesiąc z przelaniem zgromadzonych środków. My na dzień dzisiejszy zakończyliśmy z nimi współpracę i przechodzimy do transferuj.pl (niższe stawki, przelewy w 24h i dostępny moduł do WHMCS).

Jesteś pewien, że konfiguracja jest taka: 2 x Intel Xeon X5650 2 x AMD Opteron 6172 a nie taka 2 x Intel Xeon X5650 1 x AMD Opteron 6172 Bo dziwne, aby serwer z dwoma prockami AMD kosztował tyle samo, gdy cena w maju Xeona X5650 według cpubenchmark wynosiła $1017, a AMDka $1978, czyli prawie dwa razy tyle. Wyniki testu też wskazują prawie dwa razy większą wydajność: Xeon = 7970 pkt., Opteron = 13610 pkt.

Przepraszam za odkopywanie starych tematów, ale chciałem się jedynie ustosunkować do wypowiedzi: To zdecydowanie dość poważna nadinterpretacja. Pisząc o regularnych backupach dokładnie to mieliśmy na myśli. Niejednokrotnie przywracaliśmy dane z usuniętych baz danych lub kont klientów. Po prostu regulamin zwalnia nas z obowiązku ich udostępniania - przykład gdy możemy skorzystać z tego przywileju: klient co chwilę kasuje jakieś pliki i prosi regularnie co kilka dni o przywrócenie konta.

Ponad rok temu przeniosłem pewien duży serwis internetowy (działa na 3 serwerach fizycznych) właśnie z lighttpd + fastcgi na nginx + php-fpm i po tym czasie mogę spokojnie powiedzieć, że zmiana była zdecydowanie na plus. Akurat w moim przypadku strona przyśpieszyła - fpm jakoś lepiej sobie radził z dużą liczbą procesów PHP . Cała konfiguracja wydaje się też bardzie stabilna niż poprzednia. Oczywiście jeśli jeszcze nie masz zainstalowanego, to polecam dodać do konfiguracji XCache.

Jak najbardziej polecam NGINX'a. Poradzi sobie znacznie lepiej niż standardowa konfiguracja Apache'a.

Przy aktualizacji musiało Ci wykasować wpis odpowiedzialny za przekierowanie zapytań do php-fpm. Dodaj do pliku konfiguracyjnego danego vhosta (zmieniając oczywiście ścieżke): location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /home/serwer/public_html$fastcgi_script_name; include fastcgi_params; fastcgi_param SERVER_NAME $http_host; fastcgi_ignore_client_abort on; }

GłowaNet miał pełne prawo zablokować serwer za podanie niepoprawnych danych osobowych. Nawet zamawiając serwer za granicą nie uda Ci się tego zrobić bez ujawnienia swoich danych - musisz w końcu zapłacić za usługę, np. poprzez Paypal, a posiadając konto w Paypalu też musiałeś potwierdzić swoją tożsamość. Co do samej legalności strony, to jeśli obawiasz się, że jest niezgodna z polskim prawem, to raczej odpadają wszystkie polskie firmy, gdyż polskie firmy nawet posiadając serwery za granicą podlegają pod polskie prawo.

W całęj historii firmy, czy to za czasów cyberdusk.pl, czy też hostpark.pl nie było przerwy w działaniu wynoszącej 2 tygodnie - powiem więcej: nie było nawet tygodniowej. Jedna z dłuższych przerw miała miejsce kilka lat temu, gdy padła płyta główna na jednym z serwerów, ale przerwa trwała może jakieś 12 godzin. Niezależny monitoring serwerów działający od 2009 roku pokazuje status na poziomie 99,5%-99,8% (w ramach kont oferujemy SLA) Nie było w tym żadnej teorii spiskowej - dwie marki zostały połączone w jedną i podjęto decyzję, że pozostaniemy przy hostpark.pl, a nie cyberdusk.pl

Skoro zadajesz takie pytanie, to pewnie nie masz zbyt dużego doświadczenia. Dlatego polecałbym Ci CentOS lxadmin, czyli z panelem administracyjnym LxAdmin.

W Debianie plik konfiguracyjny ma nazwę /etc/mysql/my.cnf i trzeba wstawić do niego pod "[mysqld]": default-character-set=utf8 default-collation=utf8_general_ci character-set-server=utf8 collation-server=utf8_general_ci Potem już tylko restart MySQLa: /etc/init.d/mysql restart

Możesz przypisać sam proces, a nie aplikację do danego CPU/rdzenia. Jeśli aplikacja startuje nowe procesy, to tylko proces macierzysty zotanie przypisany do wskazanego CPU, reszta według schedulera systemowego. Ale jeśli wystarczyłoby Ci przypisanie samego procesu, to zainstaluj pakiet schedutils Jeśli będziesz chciał przypisać np. proces o ID 12344, wystarczy wykonać: taskset -c 3 -p 12344 czyli proces o PID 12344 ma być uruchamiany na trzecim CPU/rdzeniu lub taskset -c 3,5 -p 12344 może być uruchomiony na trzecim i piątym rdzeniu

Jeśli chodzi o MySQL, Apache i większość innych programów, to potrafią z powodzeniem korzystać z wielu rdzeni bez potrzeby jakiegoś specjalnego przypisywania ich do konkretnych CPU.

Przy przenosinach właściciele zawsze byli informowani przez Hetzner o przenosinach na wiele tygodni przed. Więc skoro nie otrzymałeś powiadomienia, to wyłącznie wina pośrednika, który nie przekazał Ci tej informacji.

Zmień RewriteBase / /home/pawel/domeny/zapromuj.pl/public_html na RewriteBase / i zobacz, czy wstawienie znaków "/" przed index.php pomoże, czyli np.

Wynik dla konfiguracji: VPS XEN, 512MB RAM, Procesor: 1 x 2Ghz, Debian 5 x86_64 System: xxxxx.vps.hostpark.pl: GNU/Linux OS: GNU/Linux -- 2.6.18-194.32.1.el5xen -- #1 SMP Wed Jan 5 18:44:24 EST 2011 Machine: x86_64 (unknown) Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968") CPU 0: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz (7021.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET, Intel virtualization 11:36:08 up 13:14, 1 user, load average: 0.00, 0.00, 0.00; runlevel 3 ------------------------------------------------------------------------ Benchmark Run: Sun Jan 16 2011 11:36:08 - 12:04:18 1 CPU in system; running 1 parallel copy of tests Dhrystone 2 using register variables 21316060.9 lps (10.0 s, 7 samples) Double-Precision Whetstone 3384.9 MWIPS (10.0 s, 7 samples) Execl Throughput 2095.8 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 360761.2 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 95674.9 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1030160.4 KBps (30.0 s, 2 samples) Pipe Throughput 552412.0 lps (10.0 s, 7 samples) Pipe-based Context Switching 144500.0 lps (10.0 s, 7 samples) Process Creation 4494.9 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 4211.5 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 558.7 lpm (60.1 s, 2 samples) System Call Overhead 578045.7 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 21316060.9 1826.6 Double-Precision Whetstone 55.0 3384.9 615.4 Execl Throughput 43.0 2095.8 487.4 File Copy 1024 bufsize 2000 maxblocks 3960.0 360761.2 911.0 File Copy 256 bufsize 500 maxblocks 1655.0 95674.9 578.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 1030160.4 1776.1 Pipe Throughput 12440.0 552412.0 444.1 Pipe-based Context Switching 4000.0 144500.0 361.2 Process Creation 126.0 4494.9 356.7 Shell Scripts (1 concurrent) 42.4 4211.5 993.3 Shell Scripts (8 concurrent) 6.0 558.7 931.2 System Call Overhead 15000.0 578045.7 385.4 ======== System Benchmarks Index Score 683.8

Zajmujemy się technologiami internetowymi od 1999 roku, a od marca 2003 działamy jako firma webhostingowa. W tym czasie zaufały nam tysiące klientów. Naszym celem jest pogodzenie ze sobą teoretycznie dwóch przeciwstawnych słów - jakości i ceny. Profesjonalny hosting nie musi bya drogi i nasza oferta na hostpark.pl jest tego dowodem. Proponujemy usługi na światowym poziomie po bardzo konkurencyjnych cenach.

Źródło: http://www.vat.pl/bez_podpisu_faktury_vat_315.php Tak więc PDF po wydrukowaniu spełnia wszystkie wymagania

Może pojedyńcze procesy nie generują dużego obciążenia, ale z vmstat widać, że system ma co robić. Obciążenie procka na poziomie 50% to nie mało, a dodatkowo wykonuje dość sporo przełączeń kontekstu (pozycja cs w vmstat) - pewnie masz sporo różnych procesów i system jest zajęty przełączeniem się między nimi.

Na screenie z vmstat nie ma nic podejrzanego. Wrzuć jeszcze może wynik działania "top".

Sprawdź może, czy w zakładce Connection/SSH nie masz czasem zaznaczony Preffered SSH Protocol version "1 only" lub "2 only" Sprawdź też, czy działa jak podasz IP, a nie hostname.

Ze wspomnianych już to ATM i NASK, ale warto też popytać bezpośrednio u dużych operatorów: GTS Energis TK Telekom Dialog Crowley

Niestety tak działa właśnie wersja 2.3.5. Trzeba wrócić do wersji starszej, aby procesy były tworzone na podstawie użytkownika, a nie vhosta.

Jeśli fora działają na vBulletinie, to zainstaluj sobie XCache ( http://xcache.lighttpd.net ), a w pliku konfiguracyjnym includes/config.php ustaw: $config['Datastore']['class'] = 'vB_Datastore_XCache'; nie dość, że xcache przyśpieszy kilkukrotnie uruchamianie skryptów php, to jeszcze z pomocą tego wpisu w konfiguracji najczęstsze zapytaqnia do serwera MySQL będą cacheowane w pamięci podręcznej XCache (zmniejsza przynajmniej o połowę liczbę zapytań do serwera baz danych.

Google is your friend Niezbyt pochlebne opinie o tej firmie: http://www.webhostingtalk.com/showthread.php?t=896149 http://www.webhostingstuff.com/review/AltusHostcom.html

Akurat w sprawach hazardu wydaje mi się, że UK jest bardziej liberalne niż USA. Nie bez przyczyny największy serwis pokerowy, PokerStars.com trzyma swoje serwery w Wielkiej Brytanii, a nie w USA. W Ameryce funkcjonuje już ustawa antyhardowa i dlatego wiele serwisów ma obowiązek blokować dostęp dla graczy z USA. Co nie zmienia faktu, że mieszkając w Polsce, podlegamy pod obowiązujące tutaj prawo. Hosting dla stron hazardowych w UK: http://www.gamblingsitehosting.com/ W Kanadzie: http://www.amrayhosting.com/adult.html (dla stron hazardowych i erotycznych opłata jest trochę wyższa) Hosting i kompleksowa obsług na Kostaryce: http://www.slogold.net/