malu

Utrzymywanie tak długo połączeń TCP zapewni przy takich wartościach i nieco większym ruchu zapchanie apache. Przy małej ilości pamięci ram i tak wysokiej wartości MaxRequestPerChild - może spowodować to nie oczekiwany wyciek pamięci i zapchanie się znacznej części ramu nikomu nie potrzebnymi pierdołami. Wartość 500-1000 jest w tym wypadku jak najbardziej trafiona. Timeout 30 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 1 <IfModule mpm_prefork_module> [...] MaxSpareServers 5 MaxClients 32 # ważne, żeby tu był limit MaxRequestsPerChild 1000 </IfModule> Taka konfiguracja powinna się dobrze spisywać przy nie wielkim ruchu, ale przecież nie ma sensu puszczać dużej ilości ruchu na VPS, który raczej powinien być traktowany w celu zabawy. Co do "cachera" php. Doradzam xcache lub eaccelerator. APC - odradzam, ponieważ nie mogę znaleść bugfixa do niego aby naprawić pewien błąd :-))

Hmm, i nadal chodzi

Eaccelerator czy APC czy xCache głównie służy do odciążenia procesora serwera, gdyż skrypty nie muszą być każdorazowo liczone. To przyspieszenie paro krotne mogło być zauważalne w dobie starych procesorów, teraz procesory są bardzo szybkie, a cache służy głównie po to by odciążyć procesor. Używam tego i tego. Obydwa działają podobnie, jednak większe zaufanie mam do eacceleratora.

Debian,slackware,pld CentOSa osobiście nie znoszę - jak i każdego RPMowca(yum, i up2date którego pewnie nikt nie pamięta) prócz PLD(poldek) :]. Poldek roxx i tyle :]

Na przyszłość poszukaj pakietów w repo. .A nie głupimi tematami serwujesz.

Tak, jednak miarodajność AB jest naprawdę warta zwrócenia uwagi. Bo nie każdy serwer działa na identycznej zasadzie .

1. W panelu jest :-)) Poszukaj. 2. z tego co pamiętam to /usr/local/directadmin/data/templates

Nie wiem jak Ty Adam, ale według mnie nikt tam nie stracił "miljonów". Miliony możliwe, ale "miljony" z pewnością nie!

Nie powinno być problemu po dist-upgrade. Czasami może się zdarzyć, że będzie jakieś "nie porozumienie" w konfiguracji. Jednak tak jak pisałem nie powinno być z tym problemów, a jeżeli już to łatwe do naprawienia.

Nowsze... na etchu to same staruszki.

kielce ... hmm kly.pl +idn, kielczyska.pl :P

Paczki debiana są mocno "po patchowane" dlatego odradzam korzystanie z nich na serwerze produkcyjnym. Czasami potrafią utrudnić życie a więc "source". Jednak, jeżeli nie masz czasu, to paczki. Ale zmień etcha, chociażby na lenny`ego jak chcesz z paczek instalować.

Pierdoły gadasz...

91.121.85.100 -> Proszę. Nie lepiej spingować ovh.fr/ovh.pl ?

SCZ -> Miałeś już okazje testować nowe dyski SSD ?

A masz poprawnie skonfigurowaną w ogóle quotę? Jak już napisałem w innym wątku, na pewno nie jest to wina poundhost. Jak czytam takie pierdoły to normalnie mnie szlag trafia. Quota podstawą w serwerach dedykowanych? Jeszcze nie spotkałem się z serwerem/systemem (czystym), który miał zainstalowaną quotę. Ale przecież Ty to doskonale wiesz, bo jest google.com

To co piszesz to istna bzdura! Serwerem zarządzasz Ty a nie ich firma, chyba że wykupiłeś usługę menaged. Błędnie zainstalowany OS ? O czym to w ogóle mówisz? Może nie potrafiłeś zainstalować quoty i dodać odpowiedniego wpisu do fstab ?

Bazy w sensowny sposób nie po limituje, chyba że nada bazą limit na ilość zapytań. Ale nie da się tego zrobić w sposób % względem zużycia CPU. Zaś jednak obciążenie interpretatora php da się zmierzyć, a nawet limitować.. I podpowiedziałem Ci już jak to zrobić. Potrzebujesz php działającego w fcgi/cgi z workerem suexec/suphp. Procesy będą wtedy uruchamiane z UID danego użytkownika.

http://directadmin.com/forum/showthread.php?t=19688 -> Miłej lektury.

Tak możesz. Potrzebujesz php działającego z wrapperem (suexec lub suphp). Następnie możesz limitować to np. za pomocą ulimit. :-))

Z tego co się orientuje kei = dinfo. Jeżeli chodzi o rejestracje domen. A więc jeżeli ktoś poleca kei to ja od siebie polecam vbiz.pl, który również jest partnerem dinfo.pl

Ostatnio miałem pewne zlecenie w firmie w moim mieście. Zajmują się bannerami reklamowymi, jednak z tego co wiem również nadrukiem na koszulki. Więc jak zainteresowany to pisz, dane walne na PW ;]

Co ma pierwsza wojna światowa do ignorancji oles(ś)a. Normalnie czasem Cię czytam i wydaje mi się, że NVU powinien zacząć się bać konkurencji.

Zacznijmy od tego, co Ci zrywa połączenia.

Według mnie jest to dobra decyzja, i powinna wyjść na dobro dla Cpanelu. Osobiście cieszyłbym się również z oficjalnego wsparcia dla Debiana.