Dotaz: Distribuce na server AMD64

[Karel Nagy]

Dobry den,
prohledaval jsem forum, ale nenasel jsem uspokojivou odpoved, tak pisu tento dotaz, protoze me zajima vas nazor.
Koupili jsme pocitac, ktery bude databazovym serverem. Jedna se o AMD Athlon(tm) 64 Processor 3500+ se 4GB RAM. Pobezi na nem relacni databaze Firebird 1.5.1 (neni 64 bitova, ale dalsi verze 1.5.2 uz 64 bitova bude). Databazovy soubor ma k dnesnimu dni asi 2GB a pomalinku roste.
Jakou byste nasadili distribuci (64-bitovou) a jaky souborovy system byste pouzili vy?
Diky za vase nazory.
Karel

Odpovědi

[hmm]

Jelikož jsem FreeBSDčkař, tak FreeBSD... :)

Ne vážně...

Jde o to, s čím umíte/co znáte. Já preferuju FreeBSD proto, že má lépe vyřešený konfiguráky, má balíčky a systém portů najednou, jsou tam bezpečnostní vymoženosti typu (secure level kernelu, příznaky, několik firewallu, atd.)

Přeji dobrou volbu...

[Karel Nagy]

Spis bych preferoval Linuxovejsi distribuci . S tou bezpecnosti (a ted ji nechci podcenovat) by me absence "nekolika firewallu" na databazovem serveru zas az tolik nevadila, protoze od toho jsou firewally na jinych serverech. Tento je ciste databazovy.
Karel

[Nikola Ciprich]

dobry den, no pokud to je pro Vas kriticky server (a vypada to ze by mohl byt), tak bych asi zvazil pouziti nejake enterprise distribuce, at uz treba Redhat, nebo jine. s pozdraven nc

[Karel Nagy]

Uvazovali jsme o tom, ale spise o jejich free alternativach - OSCent, WhiteBox, .... Mate s temito distribucemi nejake zkusenosti?
Karel

[CIJOML]

Vcelku spokojene pouzivam 64bitovou variantu Debianu testing :)

[SYSMAN]

FedoraCore3-x86_64

[imro]

Ako suborovy system ti z vlastnej skusenosti doporucujem XFS.Je to jeden z najprepracovanejsich(podla mna) a najodskusanejsich(dokonca aj podla IBM,ktore preferuje vlastne JFS)filesystem na svete.Okrem toho ma velmi dobre nastroje na spravu,zalohy a podobne.U nas mame 3 databazy-130 MB,650MB,3.5GB ktore bezia na XFS a nikdy neboli problemy.Kedysi som bol priaznivec ReiserFS,ale ten ma uz sklamal dvakrat a viac ryskovat nemienim. Co sa tyka distribucie,ja osobne by som pouzil Debian testing,ktory sa ma o par tyzdnov stat stable.Ale to je skor tvoja osobna volba podla tvojich skusenosti,vedomosti a podobne.To vies,sto ludi sto chuti.Ak mate peniaze na podporu,tak velmi dobra volba je RedHat. Inac,daj potom vediet,ako si sa rozhodol.

[ghostmonk]

Pokud do linuxu více vidíte - nebo máte trochu času prečíst pár stránek na úvod, tak použijte Gentoo. http://www.gentoo.org/proj/en/base/amd64/technotes.xml

[Käyttäjä 11133]

Taky bych poradil pouziti Gentoo. .-)

[makak]

Momentalne (uz par mesiacov) riesim ten isty problem, takze hoci nie som prave guru, myslim ze Vam viem poradit. 1. Zabudnite na suse..
2. Este raz zabudnite na suse.. Viem, citim, ze po nom poskulujete, ale je to zradna pasca..(som vlastnikom zelenej skatule). ak ste ani teraz nezabudli na suse, vedzte, ze budete mat strasne problemy a nakoniec zistite, ze za to moze to ich 'jadro'. Ten clovek, co chvali xfs ma absolutnu pravdu. Je to prepracovany a fakt vymakany filesystem. A to co hovoril na adresu reiserfs je taktiez 100%-na pravda. Pokial sa rozhodnete pre linux a nedate tam jadro novsie ako 2.6.8, xfs si sice uzijete na normalnej particii, ale ak chcete mat raid10 (myslim , ze databazovy server si to priam pyta), budete sa s jadierkom musiet trosku pohrajkat.. ake CFLAGS nastavite a tak.. ale to vlastne budete musiet aj tak..
Neviem, ako zatazovany bude ten Vas server, ale ak bude load prekracovat 2.0, a budete tam mat starsie jadro ako 2.6.8, budu problemy so stabilitou.
3. Ine linuxy som neskusal.. dobre skusenosti na 32 bit mam s mandrake 10

Jednoznacne: momentalne najlepsie riesenie pre amd64 pre produkcny server (neverili by ste ako sa ludia smeju, ked pocuju 'amd64 ? co je to za server ?! haha..' ) JE:

FreeBSD 5.3-stable

Stabilne ako papier na skle, bezpecnost sama o sebe, firewall z openBSD, porty, po update to cele skompilujete s optimalnymi nastaveniami:
CFLAGS= -O2 -ffast-math -march=athlon64 -mtune=athlon64 -pipe -frename-registers (teraz som Vam usetril vela testovania ) sem tam patchujete.. rychlo sa na to zvyka a je to koplexny OS ...- (nie jadro + GNU) (Linuxaci nehnevajte sa na mna..) Behom jedneho dna si pekne na novy OS zvyknete a budete spokojny.. uvidite.

[Michal Kubeček]

Znovu vás prosím: nechte už té propagandy. Na jádře SuSE není nic tak tragicky hrozného, jak tady pořád dokola vykřikujete, a už vůbec není pravda, že kdo zkusí SuSE 9.1 na AMD64, bude mít určitě strašné problémy. Problémy, které jste měl, byly téměř jistě způsobeny něčím úplně jiným a několik lidí vám to celkem jasně napsalo. SuSE je distribuce jako kterákoli jiná, má své výhody a nevýhody (jako kterákoli jiná - a stejně jako je má FreeBSD); není to ani spása lidstva ani spolehlivá cesta do pekel. Takže, znovu vás prosím, nestrašte zbytečně ostatní a přestaňte tady trousit bludy.

[makak]

Suse bolo fain a je fain, pokial ho nechcete extremne zatazovat.. Je to super OS na desktop, pracovnu stanicu.. Jednoducha sprava (YasT2) Jednoduchy update, komfort, .. ale nie na produkcny server.. A tomu chlapikovy ide o produkciu. Ja neviem, asi je to defaultnymi nastaveniami sysctl, alebo co.. ale keby to chcel vsetko opravovat bolo by to horsie ako si to cele kompilovat z linux from scratch..A aj tak by to nikdy nedal dokopy na taku uroven aby sa to vyrovnalo veciam, ktore su na to urcene.. Povedzme, ze chlapik by si uplne zablokoval akekolvek lokalne prihlasovanie a mal pristup len cez ssh (pri niektorych housingoch je to nutnost), a root by bol premenovany inak (napr. matejko UID 0). To by ale bola sranda, keby tak urobil update a mily suse by mu vyrobil roota bez hesla a zablokoval matejka.. Taketo a podobne ine podrazy to robi, ked to chce clovek aspon ako-tak zabezpecit..
Suse je urcene na desktop a menej skusenym resp. zacinajucim linuxakom. Sam som sa na nom dost naucil, a som za to vdacny, ale je to len polevka pred hlavnym jedlom. na server by som to nedaval. jedine ze by som to studoval do poledneho Flagu.. a na to fakt neni cas.

[Michal Marek (twofish)]

Povedzme, ze chlapik by si uplne zablokoval akekolvek lokalne prihlasovanie a mal pristup len cez ssh (pri niektorych housingoch je to nutnost), a root by bol premenovany inak (napr. matejko UID 0).

A co třeba zakázat přihlášení roota přes ssh, než takovéhle kejkle?

[makak]

samozrejme ani root na ssh nemal pristup.. len jediny uzivatel.. nie root,.

[Michal Čihař]

No na extrémní zátěže je spíš SLES, prostě od krabicové verze nemůžeš čekat nějaké extra vyladění na servery...

[Michal Kubeček]

Už jsem vám to napsal několikrát: používám SuSE i na velmi zatížených serverech, prováděl jsem na tom i dosti náročné zátěžové testy na i386 i x86_64 (dokonce i právě s RC verzemi Firebird 1.5.2) a žádné problémy toho charakteru, jaký popisujete, jsem nezaznamenal - kromě těch, které byly způsobeny vadnou pamětí. Totéž vám napsalo i pár dalších lidí, přesto pořád pokračujete v pomlouvání této distribuce. Proč?

Klišé typu "SuSE (Red Hat, Mandrake) se hodí jen na desktop, na server se nehodí" bytostně nesnáším. Je to totiž naprostý nesmysl. Proč třeba Oracle certifikuje své produkty pro Red Hat a SuSE? Že by byly určeny desktopovým uživatelům? Asi ne. Jistě, SLES se na server určitě hodí více než SuSE x.y Professional a RHEL více než Fedora Core. Jenže důvody, proč tomu tak je, by spolehlivě vyřadily ze hry všechny ostatní alternativy, o kterých tu padla zmínka.

A ještě drobnost: váš příklad s přejmenovaným rootem mi připadá poněkud přitažený za vlasy. Můžete mi sdělit jediný praktický důvod, k čemu by to mělo být dobré? Napadá mne leda "zabezpečování" podle hesla security by obscurity. Chápal bych důvody pro zavedení druhého uživatelského účtu s UID 0, ale tam zase nevidím, v čem by měl být problém. A když už o tom přemýšlím, nenapadá mne ani důvod, proč blokovat lokální přihlášení - natož důvod, proč by to snad měla být nutnost.

[makak]

No.. ja som zo slovenska.. Mozno je u Vas situacia v hostingoch ina, ale ja mam zle skusenosti.. Preto to zablokovanie lokalneho roota.. na ssh samozrejme tiez root nemal pristup.. len uzivatel 1001 -> su. Potom su tu aj dalsie argumenty.. napr. pri upgrade kernelu zmena nazvov SATA diskov na radici VIA23XX(raid0,1) z hda na sda -> zle zaznamy v /etc/fstab a viete si domysliet, co nasleduje po reboote... Ono to urcite zalezi na vybere hardwaru.. Suse nemam rad preto, lebo vdaka tomu, ze som sa s tym tak prplal, som v strate 200000Sk, nakolko mi server este furt stoji a pripadam si jak neschopny blbec.. tak to predsa musim na nieco zvalit a nejak sa utesit..

[Michal Kubeček]

Pořád jste nevysvětlil, v čem je podle vás systém s povoleným lokálním přihlášením méně bezpečný. Pominu-li tedy variantu, že heslo je tak hloupě zvolené, že ho lze uhodnout útokem hrubou silou z klávesnice - ale to by byl problém sám o sobě. A když už jste se o tom zmínil, ani v zákazu přihlášení roota přes ssh a přihlašování na normálního uživatele a používání su nevidím žádnou velkou výhru. Spíš bych chápal zákaz autentizace heslem (autentizace pouze klíčem) nebo restrikci IP adres klientů.

[makak]

A este prakticky priklad, preco premenovat roota.. Pozeral som si logy, a kazdy, kto sa o nieco pokusal, sa snazil nalogovat na uzivatela root.. no.. a ked tam ten uzivatel neni, tak sa asi nenaloguje, aj keby heslo vedel... aspon dufam.. ak nie, tak ma opravte..

Ak bez problemov pouzivate suse na serveroch, tak urcite nie s ich jadrami.. ak ano, tak uzrcite nie na raid1+0 s xfs .. pretoze to sa size da vytvorit aj spravit mkfs, ale pri mount toho raidu s xfs kernel spadne..... je to vyriesene az v 2.6.8 - a to je az v suse 9.2

[makak]

Znemoznenie lokalneho prihlasenia a sifrovany filesystem je jediny sposob ako sa chranit pred prevadzkovatelom housingu.. Ako vravim, mam velmi zlu skusenost s jednym housingom a neprajem nikomu cestovat pol dna k serveru, ktory nebol 8 hodin pristupny a zistit, ze je OK a je v nom strceny mrtvy sietovy kabel.. (co sa asi tak dialo tych 8 hodin ked server po prevoze do ineho housingu zdochol po par hodinach ?) - ja blb som nevygeneroval nove kluce a nenahodil nove hesla..

[makak]

co by aj tak nepomohlo, ked tam mohol byt nejaky backdoorik..

[Michal Kubeček]

Pořád čekám na odpověď, v čem vám pomůže zákaz lokálního přihlášení. Pokud je heslo zvoleno aspoň trochu zodpovědně, zkoušením z klávesnice ho v historicky dosažitelné době nezjistíte. Rozhodně ne dříve, než si toho někdo všimne. Budeme-li se bavit o útočníkovi, který ten server přebootuje, pak je zákaz lokálního přihlášení (jakož i jakékoli jiné nastavení systému) zcela irelevantní. O šifrovaném filesystému se zmiňujete poprvé, to je samozřejmě možnost, ale se zákazem lokálního přihlášení to nemá vůbec nic společného.

[makak]

Vyznam to ma ten, ze vas to chrani pred Vami samotnymi.. totiz.. V housinu su kamerky.. a tie sleduju vase prsteky, takze ked sa nalogujete lokalne, ste slusne povedane v (k)analy..

[Michal Kubeček]

Tak to už je opravdu vrchol demagogie, to už byste mohl tvrdit, že základem bezpečnosti je přivařit počítač ke stolu, protože vás to ochrání před tím, abyste ho vyhodil z okna. Pokud se bojím kamer (mimochodem, viděl jste někdy obraz z typické bezpečnostní kamery?), tak přeci nebudu dělat něco, čím bych mohl heslo kompromitovat. Takže v takovém případě bych použil třeba jednorázová hesla, aby i útočník se sebelepší špionážní kamerou měl smůlu. Jaké preventivní opatření použijete proti tomu, abyste si heslo napsal fixou na klávesnici? Ne, to není absurdní: považuji se za svéprávného, takže považuji-li nějaké jednání za nebezpečné, pak se ho jednoduše nebudu dopouštět; nebudu vymýšlet způsoby, jak bych si ho zkomplikoval.

[makak]

vidite.. hovorite, ze som demagog, a dopadol som ako najvacsi optimista - so serverom doma na stole.. paranoie nikdy nie je dost.. Moj priklad to len potvrdzuje.

[Zdeněk Burda]

to je takovy problem si zpalatit v serverhostongu zamykatelnou skrin? Kdyz mas na kvalitni pripojku pro server az domu a klimatizaci a zalozni zdroj a generator a ja nevimcojeste, tak snad ta skrin neni problem, ne?

[makak]

Uz mam skrinu.. ono totiz uz mam druhy housing.. V tom prvom boli len police.. Vies, toto je moj prvy server a nikdy predtym som nebol v ziadnom housingu.. tak asi zato som tak dopadol.. bola to mala spinava zaprasena sopa niekde zastrcena v nejakej skole... co mam este povedat.. Smola nechodi po horach..

[Michal Kubeček]

1. To, co tady propagujete, je přesně zmíněná security by obscurity. Tedy přístup, který se zásadně uvádí jako vzorová ukázka toho, jak nepostupovat.

2a. SuSE používám s distribučním jádrem. Výjimkou byl jen po určitou dobu můj domácí počítač, do něhož jsem si dal desku s řadičem Highpoint 372, který v té době nebyl distribučním jádrem podporovaný. A pak ještě v době, kdy jsem se rozhodl ze studijních důvodů používat jádro řady 2.6 pod SuSE 9.0 (i když mne k tomu nic nenutilo), ale to bych na serveru v žádném případě neudělal.

2b. Ne, nepoužívám kombinaci RAID 1+0 s XFS. Už proto ne, že když jsem jednou zkoušel (nevím přesně v které verzi) při instalaci použít XFS, instalační program mne upozornil, že implementace XFS není ještě dostatečně stabilní pro produkční nasazení. A opět: pokud se chyba projeví už při mountu, nedokážu si představit, že bych takovou věc dal na produkční server, aniž bych to nejdřív vyzkoušel na sucho.

2c. pokud píšete, že je chyba vyřešená v 2.6.8, chápu to tak, že se týká i vanila jader. Je-li tomu tak, opět nechápu, proč plivete špínu na SuSE, když ta chyba nevznikla u nich.

2d. reportoval jste tu chybu? Jakou odpověď jste dostal?

[makak]

1.chyba je vyriesena az v suse 9.2 - jadro 2.6.8 .. to znamena, ze kto ma 9.1 a nema odvahu experimentovat mimo yast, ma smolu. Je divne, ze mandrake 10 s defaultnym jadrom 2.6.3-nieco ten problem nema.
2. Pri instalacii Vas suse neupozornil, ze xfs este neni vhodny na produkciu (ak ano, tak mozno nejaky starsi suse), ale Vas upozornil, ze / resp. particia, z ktorej sa bootuje nemoze byt xfs. lebo lilo tusim z toho nevie bootovat. pokial to date na iny mountpoin ( /usr ) tak to v pohode zozerie..
3. ano reportoval som chybu..
3.a, Vypytali si ticket z instalacnych CD. tak som ho poslal.. 3.b, Napisali mi, ze v mojom pripade bude lepsie pouzivat vlastne jadro (Vanilla) a ze v tomto pripade uz nemam narok na instalacnu podporu.. To je sranda, ze ? .. potom mi to potvrdili aj po telefone, ked som volal na support.. (nejaka babenka to tam ma nastarosti)

ad 'security by obscurity' - zmena uzivatela root je jednou zo zakladnych veci, ktore treba urobit v ramci lokalneho aj sietoveho zabezpecenia..

[Michal Kubeček]

1. Zajímavé na tom není naprosto nic. Jednotlivé opravy z novějších verzí jádra se samozřejmě backportují do těch starších. Každá distribuce ovšem backportuje jiné. Nebo si snad myslíte, že v Mandrake by se podobný příklad (nebackportované opravy) nenašel?

2. Úžasné, vy víte lépe než já, na co mne instalační program upozornil. Netvrdil jsem, že to byla verze 9.1. Ale i z jiných náznaků jsem vyrozuměl, že implementace XFS ještě není úplně stoprocentní a v netypických situacích (jako je třeba právě kombinace se SW RAIDem) mohou nastat problémy.

4. To je docela zvláštní názor. Zajímavé je, že jsem se s ním zatím setkal jen u těch, kteří toho jinak o bezpečnosti moc nevěděli. Naopak ti, kteří byli odborně na výši, se na podobné techniky "zabezpečení" dívali s úsměvem nebo opovržením.

[makak]

Ano.. ja nie som ziadny expert.. som s unix-like OS asi 5 mesiacov.. intenzivne studujem.. Velmi rad sa poucim o technikach zabezpecenia. Je to pre mna velmi dolezite a budem Vam vdacny za kazdu informaciu.. Ja len napodobnujem ostatnych, ktorych som nasiel pri citani roznych for na tuto temu..

[Zdeněk Burda]

Mozna by se vyplatilo jeste nejakou dobu studovat a pak az radit lidem co je pro ne nejslepsi a vsude okolo sebe hazet spinu na nejaky nasroj/program/distribuci.

[makak]

JA nehadzim spinu.. ja sa delim o skusenosti.. Nechcem nikoho zranovat.. Myslim, ze dva protichodne nazory su lepsie ako tisic rovnakych.. a on sa z toho pouci..

[Michal Kubeček]

Přečtěte si znovu s chladnou hlavou váš příspěvek z 22.12.2004 22:16, zapomeňte na to, že jste ho psal vy a zkuste upřímně odpovědět: připadá vám to jako dělení se o zkušenosti?

[makak]

No.. mozno som trosku svojsky a impulzivny.. ale o tom je zivot.. nie ?

[Michal Kubeček]

Jinak ta změna zařízení vypadá hodně nepříjemně, ale zdá se mi dost nepravděpodobné, že by se taková změna týkala jen SuSE jádra.

[makak]

Ved preto mu radim *BSD

[Michal Kubeček]

To jsem si všiml. Jenže mezi release candidates Firebird 1.5.2 platforma FreeBSD na x86_64 není. Je samozřejmě pravděpodobné, že se časem oficiální build pro tuto platformu objeví, ale netroufám si odhadnout, kdy to bude. A než na produkčním serveru experimentovat s portací na novou platformu, to by už asi bylo lepší použít 32-bitovou verzi (což také není optimální).

[makak]

RElease je uz out... uz je stable.. treba po instalacii spravit kompletny cvsup -> make buildworld, kernel ... atd.. Firebird nepouzivam, ale hadam by to nebol problem naportovat,.. vecer Vam poviem, ci tam uz je podpora alebo nie..

[Michal Kubeček]

Asi jste přehlédl, že se nebavím o portu FreeBSD, ale o Firebirdu. Vzhledem k tomu, že ten server má fungovat jako databázový server pro Firebird, je existence a stabilita portu této databáze pro danou platformu podle mne zcela klíčová. Naportovat to samozřejmě půjde, ale otázkou je, kolik s tím bude práce a jestli ji tazatel bude ochoten (a schopen) provádět. Nemluvě o tom, že porty pro i386 FreeBSD jsou poněkud pozadu, takže uživatelská základna nejspíš není z nejbohatších.

[makak]

No.. mozno je to argument pre suse.. Vazne si myslite, ze porty vo freebsd zaostavaju ? Si pozrite aku verziu apache mate na suse 9.1 po update (je tam 2.0.49 + bezpecnostne zaplaty (mozno)) ... a potom sa pozrite na porty FreeBSD co je tam (2.0.52_4) - co k tomu dodat ? Ja viem, ze posledna verzia nie je dolezita a ze zalezi len na opravach chyb.. tak isto je to s mod_php4 aj inymi vecami co sa rychlo vyvijaju.. ja viem, ze suse to ma zato tak, ze vsadza na osvedcene veci..

prave som pozeral tie porty.. firebird tam nie je.. dalsi bod pre Vas..

[Michal Kubeček]

Celou dobu se bavím o portaci databázového serveru Firebird, protože přesně na ten se tazatel ptal. Všimněte si, že v tom původním příspěvku není ani slovo o tom, že by tam chtěl běhat Apache, zato tam naprosto jasně píše, že na tom chce běhat Firebird. A když se podívám na SourceForge, je tam pro freebsd-i386 jako nejnovější build verze 1.5.0 z května 2004, tedy s více než ročním zpožděním proti Linuxu (kde je poslední release 1.5.1 z července 2004 a v dohledné době bude 1.5.2). Kdyby klíčovou aplikací byl Apache+PHP, bylo by podstatné, jak je to s jejich podporou a výsledek by byl dost možná úplně jiný. Také to není argument pro SuSE, je to argument pro Linux obecně.

Jinak ta verze Apache toho sama o sobě moc neříká, většina linuxových distribucí updaty provádí v naprosté většině formou backportu oprav (ne upgradem na novou verzi s novými featurami a novými chybami), takže pokud v době release SuSE 9.1 (duben 2004) byla aktuální verze Apache 2.0.49 (což je poměrně pravděpodobné), je tam dodnes a bude tam velmi pravděpodobně už pořád. To ale neznamená, že jsou v ní chyby, které byly opraveny v novějších verzích.

[makak]

Mate pravdu.. prilis sme odbocili od povodnej temy... Ked budeme takto pokracovat dalej, pozvem Vas na pivecko..

[makak]

To s tym experimentovanim je fakt.. ale zda sa , ze chalan spravil tu istu chybu ako ja.. videl ze su OS s podporou amd64 , ale nezbadal, ze to este nie je celkom dotiahnute.. a kupil amd64 ..Ovsem, pri testovani athlon 3200+ XP s 512KB L2 cache a amd64 3200+ s rovankou cache a rovnakou frekvenciu 2200MHz (tie amd64 3200+ su tri typy lisiace sa frekvenciu a velkostou cache) bol v testovani apache + php+ mysql v teste ab -n 100000 -c 200 http://localhost/phpinfo.php s rovnano velkou ramkou o 2/3 rychlejsi. (za to asi moze ten 800MHz Hyperthreading - ci ako sa to vola.. ) ale aj tak.. Takze vzhladom na toto je to dobra volba.. Okrem toho amd64 ma -frename-registers, co zamedzuje mnohym buffer overflow, takze aj zvysuje bezpecnost..

[Zdeněk Burda]

Hyperthreading je u procesoru Intel P4 a je to neco jako "castecne zdvojene jadro"

[makak]

tak uz neviem ako sa to vola, ale je to na 800MHz, FX-ka to maju na 1000MHz a robi to to, ze procesor priamo komunikuje s ramkou a nejde cez chipset na doske.. Ramka sa tak stava ako keby L3 cache.. Ako sa to vola? zabudol som.. tiez je to volaco HYPER...

[Zdeněk Burda]

HyperTransport

[Ctirad Feřtr]

Hypertransport nesouvisí s RAMkou. AMD64 má prostě vestavěný řadič (respektive u některých modelů dva) DDR SDRAM přímo v CPU. Hypertransport je vysokorychlostní sériová sběrnice, na kterou se k tomu CPU připojuje všechno ostatní (AGP, PCI, ATA, porty...).

[makak]

Vdaka za upresnenie.. kazdopadne sa na to vykonovo i386 podobne vybavena nechyta ani zdaleka..

[Michal Kubeček]

Záleží na tom, jaký výkon máte na mysli. Podívejte se třeba na srovnání v článku na http://www.root.cz/clanek/2511, konkrétně na překlad jádra. Autor článku sice výsledky prezentuje tak, že Opteron vyhrál nad Athlonem XP na celé čáře, ale když se na výsledky podíváte s nadhledem, zjistíte, že tomu tak není. Poměr dosažených časů v podstatě odpovídá poměru PR ratingů těch procesorů a i kdybyste to vztáhl na poměr frekvencí, není rozdíl nijak výrazný. A to je ještě IMHO z velké části způsoben rychlejší prací s pamětí.

Pokud byste udělal analytický benchmark čistě na výkon procesoru (tj. výpočetně náročný algoritmus pracující na malém kousku paměti), nebude mít při algoritmu, nepoužívajícím 64-bitová data, AMD64 nijak zřetelně navrch. Pokud ale bude algoritmus používat často 64-bitová data, bude rozdíl značný. Jako modelový příklad bych uvedl recenzi na http://www.anandtech.com/linux/showdoc.aspx?i=2213&p=8, zejména dva extrémní případy: v John-the-Ripper MD5 je 64-bitová verze dokonce o něco pomalejší (asi nedoladěná optimalizace), ale u OpenSSL RSA-1024 je výkon 64-bitové verze více než dvojnásobný.

[Michal Kubeček]

Ty varianty se liší především tím, že jedna je socket 754 a druhá socket 939. Rozdíl v rychlosti HyperTransport sběrnice 800 vs. 1000 MHz by neměl být tak kritický (zejména pro databázi), spíš půjde o to, že socket 939 má dvoukanálový řadič pamětí, při aplikacích, které pracují intenzivně s pamětí (a nevejdou se do cache), je to docela znát. A v porovnání s Athlon XP (kde je řadič pamětí mimo procesor) je rozdíl v práci s pamětí ještě daleko výraznější.

[makak]

Ano to je presne ono..

[makak]

Zhrnem to vsecko dohromady:
linux: Nutne pouzit jadro novsie ako 2.6.8 (suse 9.1 je mimo hry ostava suse 9.2, mandrake, FC3 ...atd) FreeBSD -5.3 - v portoch neni firefox - mimo hry

Takze asi nejaka najnovsia disktribucia linuxu..

[makak]

Oprava .. v portoch neni firebird.. firefox tam zamozrejme je.. uz neviem co pysem.. je 3:18 rano a o 7:00 vstavam, takze majte sa krasne a so sorry za tie security-obscur.. no sak viete.. .. taz zatial papa.. dobru nocku..

[Michal Kubeček]

Už zase FUDujete? SuSE 9.1 je mimo hru pouze za předpokladu, že by tazatel chtěl použít tu vaši velmi specifickou kombinaci XFS a SW RAID 1+0. Pokud použije ReiserFS nebo ext3 nebo to nebude kombinovat se SW RAIDem, není na SuSE 9.1 nic špatného.

[makak]

ad :Pokud použije ReiserFS nebo ext3 nebo to nebude kombinovat se SW RAIDem, není na SuSE 9.1 nic špatného.

A tym ste povedal, ze je to vhodne len na male nasadenie..

Myslim ze poziadavka raid10 a xfs je pri databazovom serveri to najoptimalnejsie riesenie.. resp pouzitie raw particii.. pokial to spravne vyladi (myslim, co sa tyka I/O vs pristupy na jednotlive stripy a velkost blokov na filesysteme) daju sa z toho vyzdimat slusne vysledky na urovni ovela drahsich rieseni..

[Michal Kubeček]

A tym ste povedal, ze je to vhodne len na male nasadenie..

Ale vůbec ne. To, že vám taková konfigurace připadá sexy, vůbec neznamená, že je opravdu nejlepší (nebo dokonce nejoptimálnější). Především tu pracujete s jedním velmi dlouhým souborem (nebo několika málo soubory), takže na filesystému zase až tak nezáleží. Pokud tedy nepotřebujete připadat si jako velký borec, který má slavný XFS (a ReiserFS nebo ext3 jsou pod jeho úroveň), není prakticky žádný důvod, proč si s ním komplikovat život. Tím nechcí říct, že jinde XFS nebude přínosem, ale tady nevidím žádný důvod, proč ho nějak preferovat.

A s RAIDem je to také otázka. Viděl jsem mnoho pojednání na téma použití RAID 1 (mirror) vs. databáze a jediný obecný závěr, který bych si dovolil prohlásit za obecně platný, je ten, že názory se různí. V některých případech totiž při provozování databáze nad RAID 1 docházelo i k dost znatelnému zpomalení. Konkrétně v případě Firebirda je alternativou použití shadow files a také není obecně příliš jasné, která z variant je efektivnější - spíš je to třeba posoudit případ od případu.

Vzhledem k vašim relativně krátkým zkušenostem bych vám doporučoval neprezentovat vlastní názory formou jednoznačně dané pravdy. Zvláště v případě, že nejsou podloženy faktickými argumenty, ale pouze pocity.

[Eerine]

Především tu pracujete s jedním velmi dlouhým souborem (nebo několika málo soubory), takže na filesystému zase až tak nezáleží.

XFS vykazuje ve (všech co jsem viděl) benchmarcích lepší výsledky než ostatní FS právě při operacích s velkými soubory a ty rozdíly bývají často markantní, takže bych tento faktor určitě nepodceňoval.