Skocz do zawartości
dvd

Czy Taka Konfiguracja Dobra Na Serwer?

Polecane posty

Konfiguracja:

AMD Athlon 64 X2 3800+ BOX (Socket 939)

Gigabyte GA-K8NMF-9 nVidia nForce4 4x

WD Caviar RE 400 GB 16MB cache SATA

Kingston HyperX DDR 2x 1GB PC-400 CL2

 

Czy taka konfiguracja będzie dobra na początek firmy hostingowej?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrick

jeden dysk ?

Lepiej daj dwa 200 gb na raid 1.

Nie jestem zwolennikiem amd czy nie mogl bys kupic tego pentiuma ?

Pentium 3.2-3.4 GHz w HT ladnie chodzi, lecz jak myslisz nad przyszloscia to sprobuj konfiguracje na dual xeon :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Intel Pentium D 830 (S775) 3.00 GHz (2x1MB cache) BOX

Kingston HyperX DDR2 2x1GB 800MHz CL5

Gigabyte GA-8N-SLI Pro nVidia nForce4 IE

2x WD Caviar RE 250 GB 8MB cache SATA

 

tak bedzie lepije? Xenon opada sam plyta kosztuje 1400zł :/

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Juz samo to ze zadajesz takie pytanie nie wróży nic dobrego;)

Ale druga konfiguracja jest juz "niezła":)

pozdrawiam

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

To już lepsze, Xeon nie Xenon :)

Warto też dołożyć troche na dysk SCSI

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Moze troche offtopic'owo, ale jak tak patrze na ta druga konfiguracje (ktora jest calkiem calkiem :) ) to przypomniala mi sie pewna 'rada', ktora mowila o tym, ze w celu zapewnienia jak najwiekszej wydajnosci ilosc kosci RAM ma byc 2x wieksza od:

a ) ilosci procesorow,

b ) ilosc rdzeni (vide Pentium D),

c ) ilosci potokow (vide HT).

...i wlasnie mam problem, bo nie pamietam ktora odp. jest poprawna (chociaz C odpada na 99% :) ). Ma ktos o tym jakies pojecie, bo w sumie by sie taka wiedza przydala? Tylko prosze bez 'strzelania'.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Moze troche offtopic'owo, ale jak tak patrze na ta druga konfiguracje (ktora jest calkiem calkiem :) ) to przypomniala mi sie pewna 'rada', ktora mowila o tym, ze w celu zapewnienia jak najwiekszej wydajnosci ilosc kosci RAM ma byc 2x wieksza od:

a ) ilosci procesorow,

b ) ilosc rdzeni (vide Pentium D),

c ) ilosci potokow (vide HT).

...i wlasnie mam problem, bo nie pamietam ktora odp. jest poprawna (chociaz C odpada na 99% :) ). Ma ktos o tym jakies pojecie, bo w sumie by sie taka wiedza przydala? Tylko prosze bez 'strzelania'.

A może chodzi Ci o SWAP, który to powinien być 2x większy niż RAM? :)

Też coś, kiedyś, podobnego czytałem. Wybieram bramkę "a". Wygrałem coś? :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
A może chodzi Ci o SWAP, który to powinien być 2x większy niż RAM? :)

Nie... Nie chodzi mi ani o SWAP, ani nawet o ilosc pamieci RAM. Chodzi mi o ilosc kosci.

 

Też coś, kiedyś, podobnego czytałem. Wybieram bramkę "a". Wygrałem coś? :)

Mialo byc bez 'strzelania', wiec nie :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

To i ja dorzucę swoje 5 gr. Po pierwsze AMD nie jest złe o ile mówimy o procesorach pod serwer (opteron). Dla odmiany HT i Linux to dwie różne rzeczy. Więcej psuje niż pomaga. Tak samo pomyłką są procesory dual-core pod serwer - niestety ograniczenia tej architektury powowdują, że zamiast skalować się liniowo, wzrost wydajności jest tylko o około 60%.

Dysk ATA na serwer to też nie jest dobry pomysł. Od tygodnia leży u mnie maszyna w której było 8 dysków Maxtora 250GB SATA podpiętych pod 3ware 8506-12. Nie pochodziły rok czasu i... posypały się 3 z nich. Jak można sie domyślić - RAID5 sobie nie poradził.

Wynalazki takie jak SLI oznaczają płytę desktopową, która do zastosowań stricte serwerowych ma się nijak.

Nie wiem ile taki sprzęt będzie kosztował, ale według mnie rozglądnij się za słabszym sprzętem ale z prawdziwym serwerem.

Do dzisiaj mam taką fajna płytę główną ASUS CUR-DLS na serverworksie, która kiedyś kosztowała 2500 zł. I co? Efekt jest taki że mam 2GB RAMu, 2xPIII 800 i zapomniałem, że mam serwer. Zero problemów. Aha no i oczywiście SCSI. Sprzęt serwerowy to jest zupełnie inna bajka i jeżeli chodzi o wydajnośći i stabilność, więc zastanów się 5 razy zanim kupisz...

 

cyberluk

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrick
Dla odmiany HT i Linux to dwie różne rzeczy. Więcej psuje niż pomaga

 

moglbys to rozwinac ?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

patrick - warto tutaj np. wspomnieć ostatnie problemy ze stockowym kernelem CentOSa 4.x 2.6.9-22, który w konfiguracji SMP + HT robi na niektórych sprzętach cuda o którym się filozofom nie śniło (90% iowait przy kilku operacjach naraz to jedna z atrakcji).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Tak samo pomyłką są procesory dual-core pod serwer - niestety ograniczenia tej architektury powowdują, że zamiast skalować się liniowo, wzrost wydajności jest tylko o około 60%.

Cena tez nie rosnie liniowo... Poza tym zysk 60% w ramach jednego procesora fizycznego uwazam osobiscie za calkiem udany.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrick

Akurat centosa nigdy na oczy nie widzialem ale takich problemow nigdy nie mialem ;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

dev/null: Skoro tak, to wytłumacz to moim kilku serwerom w konfiguracjach Dual Xeon (HT) + Serial ATA, które teraz działają sobie spokojnie z 2.6.15.x a dziwnym trafem poddały się "mitowi", co więcej nawet developerzy RHEL tak mocno w to uwierzyli, że wydali poprawioną wersję 2.6.9-22 z dodatkowa dwójeczką parę tygodni temu ;-).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

no wlasnie, kieruj to pytanie do developerow, ktorzy po prostu nie staranie skladaja i testuja dystrybucje - ja moge odpowiedziec standardowo - od lat bez wzgledu na to czy uzywam technologi HT na zwyklych p4 czy na xeonach(singiel/dual) - SOA #1

 

reasumujac - jak sobie poscielisz tak sie wyspisz - moze czas na zmiane dystrybucji albo moze przesiadka na inny system wogole jesli to co uzywasz stwarza problemy

 

ps

inna sprawa, ze raczej kieruje sie zasada, ze jak cos dziala dobrze i nie ma uzasadnionej potrzeby zmian to nie ruszam bez potrzeby - dlatego na kernel.org nie wchodze codziennie by sprawdzic co tu przekompilowac ;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Napisałeś, że to, że są problemy to mit - a tak nie jest ;). Żadna dystrybucja nie jest doskonała, ale rzeczywiście przed dodaniem nowego "dedykowanego" kernela, wypadałoby go przetestować. Co do ruszania bez potrzeby, wiadomo, że tak nie robię, ale kiedy liczba raportowanych exploitów do aktualnie używanego rozwiązania jest >1 włącza się zdrowy rozsądek ;).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

ale chodzi tu o pewna logike - jesli cos (przykladowo ktorys kernel) z czyms tam (przykladowo tech. HT) nie wspolpracuje dobrze (ale z wczesniejszymi wersjami tego kernela wspolpracowalo) a po poprawkach tego czegos (tu jadra) juz chodzi to fakty wskazuja na jedno - ze cos zostalo za przeproszeniem spieprzone - pytanie gdzie ? ;)

 

z tad mitem jest ze technologia HT i linux to pomylka

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Jasne, ale jeśli Centek 4.2 domyślnie instaluje się z jądrem, które nie działa poprawnie z HT to jest to jednak pewien problem dla użytkownika, który zaczyna z nim pracę, nawet jeśli "naprawa" ogranicza się do yum upgrade.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

no i na tym mozna zakonczyc dyskusje - jeszcze nie raz sie przeciesz okaze, ze cos z czyms w danej wersji nie wspolpracuje OK, ale my to przezyjemy (gorzej z serwerami ;) )

 

wracajac do tematu glownego:

...pewna 'rada', ktora mowila o tym, ze w celu zapewnienia jak najwiekszej wydajnosci ilosc kosci RAM ma byc 2x wieksza od:

a ) ilosci procesorow,

b ) ilosc rdzeni (vide Pentium D),

c ) ilosci potokow (vide HT).

...

 

pierwszy raz cos takiego czytam, a mysle, ze nie uszla by mi taka zaleznosc - zreszta na podstawie mojej wiedzy (niestety nie za duzej :( ) na temat specyfiki sprzetowej takiej zaleznosci jestem jednak sklonny dodac to do kolejnej listy mitow (ale nie dosc popularnych ;) )

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Znalazlem:

 

Większa wydajność dzięki dzięki wykorzytaniu układu: 2 moduły pamięci na każdy procesor

Technologia Dual Memory-Channel Architecture polega na wykorzystaniu dwóch kanałów komunikacji pomiędzy kontrolerem pamięci a kośćmi pamięci. Dzięki temu, że dwie kości mogą komunikować się z jednym procesorem w tym samym czasie, wydajność wzrasta dwukrotnie.

W przypadku procesorów wykorzystujących technologię HyperThreading (HT) oraz architekturę Dual Memory-Channel polecamy konfigurację uwyględniającą dwie kości pamięci na każdy z procesorów.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

o, ciekawe, jakies zrodelka mozna, zeby poczytac ?

 

ps

ladnie to wszystko brzmi w opisach: "wydajnosc wzrasta dwukrotnie" ;),ciekawe czy tak samo jak z pamieciami w dual channel kiedy "wydajnosc wzrasta..." a testy przeprowadzane na aplikacjach wskazywaly srednio wzrost o 3% (co imo mozna zaliczyc do zakresu pomiaru bledu czyli w sumie wzrost zauwazalny zero % ;) )

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
moglbys to rozwinac ?

 

Oczywiście. Całkiem niedawno z corowymi developerami SUSE bardzo intensywnie walczyliśmy z problemem HT i kernela. Przez kilka miesięcy różnego debugowania, testowania i sprawdzania została opracowana łatka która sprawuje się najlepiej - tzn jest uśredniona. Jakie problemy się pojawiały? Np takie, że jak kernel był zoptymalizowany dla MySQL (przyrost wydajnośći od 8-17%), to Apache zwalanił nawet o 32%. Jeżeli podkręciło się apache'a w wersji wątkowej, to wersja procesowa leciała na łeb na szyję. I tak można wymianiać dużo, ale skoro to jest forum o hostingu zostańmy przy tych. Co ciekawe podobne zależności zauważyłem we FreeBSD i NetBSD.

Prawda jest taka, że HT został zrobiony pod Windowsa i tam sprawdza się najlepiej. Prawda też jest taka, że systemy z włączonym HT chodził znacząco krócej niż bez na tych samych prockach - serwer który miałem do testów właśnie na SUSE chodził 248 dni pod pełnym obciążeniem bez HT (został zreebotowany bo więcej nie było sensu) w przeciwieństwie do 74 dni z HT (totalny zwis).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×