[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: minimum sprzetu do debiana



On Wed, 7 Apr 2004, Janes wrote:

> rip> serwerek na odrebny komp jakie jest minimum wymagan do oblugi:
> rip> apache, php, mysql, maskarady, htb, no i super pakietu, ktory niechcacy
> rip> znalazlem: lms.rulez.pl. Pytam bo szukam czegos w sensownej cenie na allegro i nie chce sie wylozyc.
> rip> Oczywiscie instalacja debiana ;-)
>
>
> Spokojnie pójdzie już na 386sx16MHz z 4 MB RAM :)
> Ale - czy starczy Ci cierpliwości by z tego korzystać - to inna
> inszość....

tu mam pewne watpliwosci, chodzi o instalator. otoz musi on posadzic base
system, a do tego potrzebuje ramu. zauwaz ze jest pewien krytyczny moment
kiedy swap jest jeszcze nieaktywny, i instalator po prostu sie wykolei.
jesli chodzi o 386sx to fakt, debian bedzie chodzil. tylko ze ten procek
ma wydajnosc 286stek, bo ma obcieta do polowy magistrale. w dodatku
maly ram sprawi, ze zacznie sie swapowisko. bedzie sie mozna kawami
na smierc zapic :)
tak szczerze mowiac, linux ma byle jaka wydajnosc na 486/66DX
z 16MB RAM, przy odpaleniu grafiki i np. fvwm95. o KDE i podobnych
mozna zapomniec.

dla 486/33DX (od biedy SX) widzialbym role prostego firewalla
z maskarada, z niewieloma regulami filtrowania. do HIS lub max.
eth10 to sie nada.
ewentualnie serwowanie
prostych statycznych stron przez apache. w rzeczy dynamiczne bym
sie nie pakowal. takze mam watpliwosci, czy taki komp dzialalby
efektywnie jako transparent proxy ze squidem.

> Najpierw określ swe potrzeby, przewidywane obciążenie, potem dopiero
> możesz zacząć wróżenie z fusów.
> Przykłady praktyczne:
> 1. Doświadczalny MySQL: 486dx100/16MB/SCSI - chodzi całkiem znośnie,
> choć odpalenie dselecta grozi natychmiastowym złomowaniem maszyny - mieli
> chyba ze 3 minuty...

za malo ramu :)

> 2. Logger zbierający logi z kilku maszyn (dość szczegółowe, trochę
> tego w sumie jest): amd 5x86-133 (to takie rasowane
> 486)/48MB/sprzętowy SCSI-RAID 1 i 5 na zabytkowym kontrolerze DPT z 16MB
> cache - jedyne, co można mu zarzucić, to lenistwo - stoi sobie w
> kącie, prąd żłopie, a rzadko kiedy robi coś, co zajmuje mu więcej niż
> 2% czasu CPU... (no chyba, że odpalę dselecta ;)

heh. zbieranie logow to nie jest jakies niewiadomo co :)

> 3. Routerek z VPN, maskaradą, dość zakręconym firewallem, bindem z 2
> widokami, relayem smtp i paroma innymi pierdółkami: 486dx4-100/32MB
> RAM/ software RAID 1 na 2 dyskach SCSI (po 270 MB każdy:) - chodzi
> sobie i robi swoje. W dodatku całkiem nieźle sobie radzi.

w tym konfigu smtp to raczej nie na sendmailu :)))))

> 4. Rozbudowany router ADSL dla sporej sieci, bind, smtp, apache, perl, 2x
> VPN, maskarada, firewall, ntp, i kupa innych bzdetów: P200/128MB RAM/
> soft-RAID 1 na 2 dyskach IDE (współczesnych) - w wolnej chwili dołożę
> mu squida by przekroczyć magiczną barierę 0,5 ;) Nawet odpalenie
> tripwire nie wymaga przerwy na piwo:) Choć odpalanie przez apacha
> skryptów w perlu zajmuje mu ok. 3 sek... (przez zewnętrzny interpreter,
> bez mod_perl)

tak naprawde dopiero taki sprzet ma sens, zwlaszcza ze z nabyciem
za grosze czegos w tym stylu w komisach nie ma problemu. ludzie sie tez
pozbywaja takich zlomow :)
a ze squidem uwazaj, bo moze ci zatkac maszynke. wydziel na cashe squida
odrebna partycje. to koniecznosc. uzyj tez jakiegos systemu plikow
ktory potrafi sobie sprawnie radzic z drobnica. ext3 nie jest tu
najlepszy. tutaj przewage ma raiserfs, najlepiej w wersji 2
ale do tego trzeba latac kernel i utilsy. w razie krachu,
taka partycje mozna po prostu przeinicjowac zamiast naprawiac.
taki squid potrafi pozrec spora polac dysku :)

> Generalnie sprzęt klasy P100 - P200 /32-64 MB RAM powinien Ci
> wystarczyć do takich zabaw, chyba, że chcesz naprawdę dać mu po
> garach.

tu sie zgadza. na takim sprzecie odpalanie wysoko obciazonego
serwera webowego z zaawansowana skryptologia mija sie z celem,
jesli ma z tego korzystac swobodnie internet a site bedzie
popularny. ale jesli to dla wlasnych potrzeb, lub wrecz
do pisania i testowania aplikacji, sprzet jest wrecz odpowiedni
bo pozwoli szybciej wychwycic problemy wydajnosciowe tworzonej aplikacji
:) po prostu wydajnosciowe gnioty od razu wyplywaja.

znik.



Reply to: