Dotaz: procesor do serveru

[Ales]

zdravim ctouci, stojim pred problemem stavby serveru a nejsem si jisty ohledne vyberu procesoru. Je mi jasne, ze optimalni reseni je pouzit primo serverovy procesor jako je Opteron, ale ten je rekneme mimo financni moznosti. Moje otazka zni: je desktopovy procesor od AMD do serveru uplny nesmysl a ve vykonech procesoru je takovy rozdil nebo lze pouzit desktopovy procesor jako alternativu? Pokud lze, jaky stoji za pozornost?

Diky za kvalifikovane rady

Odpovědi

[frr]

To záleží na spoustě věcí - co ten server bude dělat a kolik bude mít uživatelů. Jinak není nikde psáno (ač by si to marketingová oddělení Intelu a AMD jistě přála) že server musí mít zrovna "serverový" procesor. Právě naopak, spoustě menších serverů klidně stačí desktopová platforma, nebo i něco ještě slabšího (Atom apod.) - hlavně pokud začínáte od nuly, poznáte nejlíp až na živém zvířátku, když Vám to začne drhnout na nějakém úzkém místě Ale zas aby Vás nezdržovalo, že to dlouho kompiluje nový kernel, nový software co přidáváte ze zdrojáků apod.

[Ales]

diky za vasi odpoved. Na serveru pojede apache a na nem web s cca 5000 navstevami denne. Web bude streamovat flv video a dotazy na mysql vcelku minimalne. Spise me to zajimalo principielne, jaky je mezi temi procesory. Serverove asi nemaji instrukcni sady na multimedia atd. Ale co maji Opterony navic proti 4 jadrovym phenomum.

[frr]

Podle mého MMX je ve všech procesorech - není to tak, že by ho serverové procesory měly vynecháno. Obecně serverové procesory mívají oproti svým generačně odpovídajícím desktopovým protějškům víc cache (v dnešní době L3), podporu ECC RAM, podporu více procesorů na motherboardu a pomocí jiného pinoutu jsou obchodně navázány na serverové čipsety a motherboardy (víc PCI-e lanes, víc diskových kanálů on-chip v South Bridgi, integrovaný softRAID, několik slotů PCI-e x8).

Kolik paralelně běžících streamů FLV máte v plánu? Jak bude vypadat diskový subsystém? Aby to nakonec nedojelo spíš na nedostatečnou hodnotu IOps disků, zejména v kombinaci s nevalnou optimalizací read-aheadu v Linuxu pro tento typ zátěže...

[Bilbo]

x86_64 procesory mají v základní instrukční sadě SSE a SSE2. SSE3 a další už být může, ale nemusí.

MMX je dneska pasé, MMX instrukce a registry se kryly s FPU instrukcemi a registry (takže procesor se musel občas přepínat mezi FPU a MMX módem podle potřeby) a to co uměly MMX umí SSE stejně dobře nebo lépe.

Pro server můžou být zajímavé virtualizační instrukce (pokud tam poběží virtualizace), nebo AES-NI (pokud tam poběží šifrování), což se tady asi spíš nepředpokládá.

5000 návštěv za den není zas tak moc a streaming videa? Tam pomůže spíš hodně paměti, aby to pokud možno streamovalo z diskové cache a ne z disku :)

A v procesoru se hodí hodně jader - takže nějaké rozumné čtyř- nebo více-jádro, podle toho jak moc výkonu je třeba

[sewi]

Ja bych byl jednoznacne pro profesonalnejsi serverovou platformu. Kdyz to zacne tuhnout a ja to zivej system tak je to dost blby. Server ma fungovat nepretrzite a ne se v tom porad hrabat. Jinak servery maji jeste tu vyhodu, ze se da za provozu vymenit zdroj, HDD. Diagnosticky LEDky a 4 1Gb sitovky.

Jinak co do volby tak ja jsem pro SUN (cti Oracle) server a je celkem jedno jestli AMD nebo Intel. Intel je ted myslim lepsi na virtualizaci coz je dalsi dobra vec. Ja mam treba spoustu serveru v KVM takze kdyz neco devel zatuhne tak se prihlasim do hosta a otocim to. Taky se tim zajisti, ze host ma porad dost systemovych prostredku protoze virtualy maji jen n-1 procesoru.

[Ales]

Predne diky vsem za prispevky. Neberu to jako samozrejmost a vazim si vasi ochoty pomoci.

Zpravidla v podobnych diskusich ctu komenty typu: kdyz nemas na hardware, tak se do toho nepoustej. Neni to tak, ze bych mel rad kompromisy, ale nakupovat servery pro korporaci a pro zacinajici web si holt zada odlisny pristup.

Opravdu bych radeji zustal na am3 platforme a upgrade nechal az na chvili, kdy kapacita nebude stacit. Diky za tip s pameti. Osadim server 4gb. Ostatni features serverovych procesoru by mozna bylo zatim navic. Ohledne I/O mam v serveru 4 esata disky ve dvou raid polich s celkovou kapacitou 4,5 TB. Server bude na synchr lince 100MB.

[AraxoN]

Keď tam nebude nejaká zložitá logika, kompresia, šifrovanie, či online zmeny kodeku tých videí, tak by na to aj obyčajný procesor mal stačiť.

Čo by som Ti skôr chcel odporučiť, aj keď to nebolo predmetom otázky a možno to ani nie je Tvoja starosť: nastav si model financovania tej služby tak, aby keď sa rozrastie, tak aby bolo aj na nákup značkových serverov. Je tragické, keď sa služba stane obeťou vlastného úspechu, množstvo klientov zahltí server, ale neprinesú so sebou peniaze na vylepšenie kapacity. Začne to sekať, ľudia sa znechutia a odídu, a celá snaha vyjde navnivoč.

[frr]

Svého času jsem si zanadával, že read-ahead v Linuxu stojí za starou belu. A zjistil jsem, že jistý Wu Fengguang už pár let vydává v LKML patche zvané "adaptive readahead". Resp. on to přestal posílat do LKML někdy začátkem roku 2007 - a zjevně tou dobou byl přijat mezi aktivní přispěvatele, stal se jedním z nejaktivnějších přispěvatelů v mm/readahead.c. Nakolik přesně a doslova se jeho "adaptive readahead" dostal do kernelu, to netuším - nicméně například tenhle commit vypadá velice slibně. Dostal se do 2.6.31 (někdy v létě 2009). Já jsem od té doby svoje zátěžové generátory neproháněl... držím palce Vašemu projektu.

[ja_kral_ll]

Vlítni do toho po hlavě, muj první server byl desktop našťouchanej do 1U :D A když jsem viděl jaký kusy šrotu doplněný kartonem se povalujou v TTC tak to byl ještě solidní kousek...

AMD určitě vyjde lépe v poměru cena X výkon. Zvaž taky jestli si spíš nekoupit nějakou VPS, protože housing není taky nejlevnější záležitost, obzvlášť pokud to chceš mít v toweru a ne racku.

[Ales]

Server nebude zatezovan ani konverzi videa ani sifrovanim, takze se tedy docasne spolehnu na 4 jadrovy phenom a 4gb ram. Kazdopadne vnimam jako nutnost tvorit financni polstar na upgrade, kdyby se sluzba nahodou chytila u uzivatelu. O virtualizaci jsem premyslel, ale je pro me dulezita diskova kapacita a tim je pro me vyhodnejsi housing.

diky

A.

[Ales]

Ma smysl kupovat repasovany server? Narazil jsem na cenove prijatelne nabidky napr. na http://www.czech-server.cz. Pokud myslite, ze ma, jaky byste mi doporucili do 15.000?

Diky

A.

[frr]

Mám v popisu práce taky reklamace svého druhu noname serverů a osobně bych si jetý server za tyhle peníze určitě nekoupil. Snad leda pokud máte z nezávislého zdroje inside informace o kvalitě provedení a statistické poruchovosti konkrétního modelu a generace konkréního značkového serveru.

I pokud to má vyměněné všecky ventilátory a hot-swap moduly zdrojů, tak jsou i další součástky, které stárnou a občas odejdou - v některých serverech backplany redundantního zdroje, v některých elyty a další věci na motherboardu (ten Vám za ty peníze při repasi těžko vyměnili), obecně paralelní SCSI je mrcha vaklavá... Pokud je to po záruce tak ruce pryč od toho. Další věc je, že starý server je spíš topné těleso než počítač výkonově na dnešní úrovni. Stejný procesorový výkon, jaký má dva-tři roky starý server, dneska dostanete z desktopu - pravděpodobně s menší spotřebou. Jenom si porovnejte počet jader, velikost CPU cache a maximální velikost RAMky. A nejnovější procesory mají pořád další a další fičury, zejména s ohledem na virtualizaci (která Vás možná netrápí). Jedna věc, která vcelku neztrácí na hodnotě, je IOps točivých disků (protože hlavy kmitají pořád cca stejně rychle) - ale kapacita, "stav tachometru" a zbývající doba záruky nejsou důvodem k nadšení. Taky RAMky nezrychlují v průběhu let až tak moc, jak by naznačoval samotný takt (vemte si, jak zároveň roste CL faktor) a gigabitové síťovky jsou taky pořád cca stejně rychlé - ale to je docela chabá útěcha Nové generace RAM technologií jdou ruku v ruce především s čím dál větší maximální kapacitou a kapacitou za korunu.

Hehe - když se podívám na ten zmíněný "repasovací" web, tak nabízené servery jsou všechno Nocona/Irwindale = Netburst s 1 MB cache a jakousi prvotní podporou EM64T. 5-6 let stará topná tělesa, RAMky jsou do toho drahé...

[Ales]

Diky moc jeste jednou za vase rady. Jak to tak davam dohromady, tak mi z toho prece jenom vychazi optimalni poridit novy server. Jak jsem psal vyse, nejsem priznivcem kompromisnich reseni a nerad bych se dockal toho, ze mi sluzba zacne kolabovat a uzivatele pujdou jinam. Provedl jsem si maly test na jinem serveru (taky desktopova verze s procesorem Sempron a 4 sataII disky :) a s upl 100mbps a zda se, ze nejvetsim problemem bude IO (i pro tak slaby procesor byl test zivacka). Hlavni ulohou serveru bude soucasny pristup k vice souborum (od 1mb az po gb) a dulezita je velka diskova kapacita - rekneme 1TB v RAID 5. Myslite, ze se toho da docilit s temi sataII disky rekneme nejakym RAIDovanim nebo jit rovnou do SAS? Poradil byste mi prosim (idealne s odkazem na konkretniho vyrobek/prodejce), jake reseni si myslite je nejlepsi? Rad bych se drzel napr. Mironetu, kde je moznost splatek. No a cena? Idealni bude vejit se do 70.000 s DPH. Diky moc jeste jednou, jsem vasim dluznikem :)

A.

[Arnošt Málek]

Doporucil bych nejaky dostatecne vykony HW RAID radic -> za me treba nejakou ARECU. Jsou vykone, spolehlive, bezproblemove. SAS asi nutne nejsou. Myslim ze kvalitni "serverove" SATA to zvladnou taky. O rychlost se do jiste miry postara radic.

Misto RAID 5 by slo taky uvazovat treba o RAID 10, na to staci 4x 500 GB disk a mohlo by byt rychlejsi. Navic, pri pouziti radice areca by to slo i vyzkouset; umi totiz online migraci, takze udelat jeden raid, vyzkouset, pomerit, pak premigrovat, zase vyzkouset ... pokud by stalo za to az takto ladit vykon.

[ja_kral_ll]

Na co HW řadič ? Slyšel jste někdy o mdadm ?

[Arnošt Málek]

Ale jiste ze slysel a dokonce ho hojne vyuzivam. Ale na produkcni server s Oraclem jsem po 5 letech s mdadm pri vymene serveru zvolil zcela zamerne Arecu ... a opravdu si myslim, ze na zatizene servery se dobry HW radic vyplati.

Ale naopak, u "obycejnych" zakazniku mam velmi casto RAID 5 ci 10 prave pomoci mdadm a SATA disku a nemam s tim zadny problem, anis vykonem ani se stabilitou.

[dustin]

Osobně bych u takového startupu nerval moc peněz do HW, když nic ještě není jisté. Koupil bych entry level HP ML115, do něj dal 4xSATA 0,5 - 1TB rychlý SATA do SW RAID10 a nakoupil 8GB ECC paměť (není nijak drahá a čím víc paměti, tím líp pro diskové cache). Vejdeš se do 25k za spolehlivé řešení s rozumným výkonem. A když se ti to rozjede, takový server se vždycky hodí do firmy a na páteř můžeš dát silnější a výrazně dražší železo s HW raidem, Xeony atd.

[frr]

+1 palec nahoru ohledně volby serveru = značka a držet se trochu při zdi s penězma. S tím HW RAIDem do budoucna moc nesouhlasím, viz můj další příspěvek. Pokud se týče vlivu velikosti RAM na diskové buffery: read-ahead se asi "nadechne" volné RAMky sám od sebe, pro write-back je případně vhodné trochu poladit pár hodnot v /proc/sys/vm/ a v scheduleru.

[frr]

Eeehhh... za tyhle hraběcí rady od stolu snad netřeba mi děkovat

Nemám přehled, kolik stojí 1U ve stojanu v housu. Mám pocit, že ušetřit 1U na serveru stojí docela dost peněz. Menší větráky pro konkrétní výkon jsou dražší a víc vibrujou... Tyhle počty jsou Vaše věc.

Ohledně diskového IO si dovolím pár nekonformních poznámek, určitě mě někdo označí za bastlíře a freetarda Vaše specifická zátěž je skutečně problematická - bohužel nedokážu kvantifikovat, jestli už ve Vašem měřítku budete muset složitě optimalizovat, nebo jestli vystačíte s nějakou duševně zdravou standardní konfigurací.

Základní fakta jsou tato: desktopový disk se 7200 ot/min (Barracuda 7200.10 až 7200.12) umí cca 60-75 random IOps. Disky o větší kapacitě (hustotě) na tom mohou být obecně hůř. 3.5" enterprise disky (Cheetah 15k) umí cca dvojnásobek - tj. nějakých 130-150 random IOps. (2.5" enterprise disk jsem v ruce nikdy nedržel.) Takto vycházejí moje měření, kde seek position je generována náhodným generátorem. Tato aproximace podle mého dost dobře odpovídá Vašemu charakteru zátěže v situaci, kdy jsou data rozházena po celé ploše disku, tj. kdy se FS zaplní (reálně byste neměl překročit nějakých 80% zaplnění kvůli fragmentaci). Zároveň desktopové disky špatně "škálují" IOps při trochu slušném řazení požadavků / short-strokingu / prázdném filesystému (vytáhnete z nich řekněme dvojnásobek IOps), enterprise disky se přizpůsobí znatelně líp (viděl jsem hodnoty 400 - 700 IOps). Možná je to dáno rotační latencí, možná dementním firmwarem/elektronikou desktopových disků... těžko říct. V případě zátěže typu "parallel readers" je dále klíčová hodnota "read-ahead size" (konfigurace OS, případně RAIDu a disků) - a má to několik háčků. Například u disků schopnost IOps je závislá na velikosti transakce (mrkněte na ten graf) - a další háčky ve vzájemné spolupráci několika vrstev v IO subsystému OS Linux.

Pokud potřebujete točivými disky dosáhnout větší počet IOps, potřebujete víc kusů disků. Zároveň potřebujete nějak rozumně mezi ně rozložit zátěž, aby se Vám jejich IOps kapacity skutečně sčítaly - což není samozřejmost.

Jednak je tu otázka, jaký RAID level, stripe size, jak k tomu připasovat chunk size filesystému, jaký vůbec FS apod.
Samotné disky nepotřebují zarovnávat transakce na nějakou pevnou velikost bloku (větší než nativní sektor). Souborový systém a jeho FS-level read-ahead taky (bohužel) nezarovnává. Read-ahead v blokové vrstvě sice rozděluje obdržené transakce tak, aby byly zarovnané na nějakou mocninu dvou (snad na read-ahead size, ale nejsem si jistý), ale nakonec stejně první a poslední "fragment" nejsou zarovnané.
A teď si vemte, že jako blokové zařízení slouží nějaký striped RAID-level (typicky 0,5,6,10,50,60). Optimální velikost transakce je zarovnaná na velikost stripe size - aby seeknul právě jeden disk. Pokud tuhle velikost o fous překročíte, nebo transakce není zarovnaná, už musí seeknout dva sousední disky (a Vám degraduje dostupná množina IOps). Zároveň by stripe size měla odpovídat nějakému zvolenému kompromisu mezi IOps a velikostí read-aheadu, tj. stripe-size == read-ahead size. Hardwarové RAIDy končí se stripe size někde na 512 kB (nebo i níž), snad jen softwarový MD RAID umí i větší stripe size (v megabajtech, vyzkoušeno). Stejně pak ten read-ahead nezarovnáte, ale je to možná lepší než drátem do oka.
Všechny výše uvedené podmínky v Linuxu momentálně nelze splnit. (Umí je splnit snad jen nativní ZFS na Solarisu, který jde přes několik vrstev.)
A v rámci "striped" levelů další záludnost skrývají "paritní" levely 5/6 (a potažmo i jejich kombinace s nulou) - u nich navíc "bolí" zápis nezarovnaný na stripe set. Čili pokud Váš mix provozu obsahuje víc jak pár procent zápisů, tyhle RAID levely jsou cesta do pekel.

Pokud použijete nějaký hardwarový RAID, tak pro něj tyhle obecné RAIDové počty platí taky, navíc budete omezen na nějakou nevelkou velikost "stripe size", a jeho scheduler je pro Vás černá skříňka. Můžete si třeba v konfiguraci zvolit (v lepším případě), jestli má být read-ahead konzervativní, normální nebo agresivní, ale tím to zhruba končí. Nevíte, jestli umí detekovat víc paralelně sekvenčně čtoucích procesů, pokud ano tak kolik apod. Taky surová průchodnost RAIDového procesoru (bez ohledu na seekování točivých disků) může být zejména u low-endových PCI HW RAIDů úzkým hrdlem. Pro normální použití jsem zastáncem HW RAIDů kvůli jejich komfortu, ovšem v tomhle případě bych spíš doporučil HW RAID vynechat

Optimální volbou pro "parallel readers" je tak nakonec skladba úložiště na způsob "množina jednotlivých disků" nebo "množina mirrorů". Disky nebo mirrory v množině optimálně nespojujte LVMkem (buď je bude strajpovat, viz problém se zarovnáním, navíc nedovolí rozumnou stripe size, nebo disky "spojí za sebou", takže budou při malém zaplnění úložiště nerovnoměrně vytížené). Vůbec nejlíp se v Linuxu chovají jednotlivé disky nebo mirrory, jednotlivě namountované (nezapomeňte na noatime), s rozkládáním zátěže v aplikaci. Heuristika rozkládání může být jednoduchá: nový soubor uložte na filesystém v rámci "množiny", který má nejvíc volného místa. Není to z mé hlavy, snad mě někdo nezabije, že jsem prozradil jeho obchodní tajemství

Dají se vygooglit zmínky, že scheduler CFQ je k prdu, že lepší je deadline (skoro základní elevator) nebo vůbec noop. Ano, CFQ je dlouhodobě optimalizovaný na "interactive desktop experience", tj. na minimální latence desktopu i ve chvíli, kdy se třeba na pozadí něco chroupe nebo kopíruje. Což je něco úplně jiného, než "parallel readers". Scheduler "noop" znamená, že se řazení požadavků vůbec nedělá, resp. nechá se zcela na libovůli hardwaru - má to smysl zejména v případě, že máte chytrý RAIDový řadič. Pro Vaši zátěž by teoreticky měl mít optimální vlastnosti scheduler "deadline". Laický popis/představa deadline schedulingu je vcelku jasný. Ono to ale není až tak jednoduché, resp. mám pocit, že reálně linuxový "deadline" scheduler funguje vlastně dost jinak, než je obecně publicisticky prezentováno. V podstatě je základem opět elevator (řazení požadavků podle seek position), který se zároveň snaží o write-combining. Další finta ale je, že každý požadavek má přiřazenou nějakou "životnost" či timeout. Pokud v tomto timeoutu není vyřízen, vypadne rovnou do "výstupní fronty" směrem k disku. A další finta je, že deadline scheduler se snaží dávat přednost požadavkům na čtení - tyto mají mnohem kratší deadline než požadavky na zápis (write-back). Takže do výstupní fronty vypadnou mnohem rychleji. Tuším se to dá trochu ladit, ale nijak zvlášť. Přitom každé blokové zařízení má svoji instanci scheduleru, takže by obecně neměl být nesmysl, dát třeba úložišti pro downloady pro čtecí transakce delší deadline, protože víme, že se jedná převážně o požadavky na FS-level read-ahead, které proto obvykle přímo neblokují aplikační vlákno. No a protože "výstupní fronta" deadline scheduleru už není dále tříděna, tak pod větší zátěží (která by teoreticky měla vyvolat maximální účinnost řazení a slučování požadavků) deadline scheduler velice rychle ztrácí vlastnosti "výtahového algoritmu" a reálně degraduje na "noop"... Většina požadavků stihne při "čekání na výtah" vytimeoutovat dřív, než se k nim disk dostane, padají do výstupní fronty, a úhledné třídění přestane existovat - potažmo se ztratí i přínos TCQ/NCQ v disku, pokud nějaký existuje. Je možné, že klasický Linusův učebnicový "jediný elevator" v Linuxu 2.4 fungoval nakonec líp

Read-ahead v Linuxu se zřejmě odehrává na dvou úrovních: ve filesystému (resp. VM vrstvě, viz mm/readahead.c) tj. nad IO schedulerem, a pak v blokové vrstvě tj. pod IO schedulerem.
Read-ahead v blokové vrstvě je hrubý a tupý, funguje "po sektorech", bude Vám přednačítat jak užitečná data tak metadata => zvyšovat read-ahead na blokovém zařízení sice jde, ale nijak si tím nepomůžete.
Read-ahead na úrovni filesystému je cestou kupředu. Toho se právě týká ten odkaz na práci Wu Fengguanga, který jsem poslal výše. Přednačítá se uživatelský stream, tzn. "užitečná data" a pouze relevantní potřebný objem metadat. Wu se snaží o to, aby "okno přednačítání" škálovalo jednak podle zjištěného "vzorce chování čtenáře", a navíc aby v rámci jednoho otevřeného file deskriptoru mohlo číst několik vláken sekvenčně na několika pozicích (a read-ahead si toho všimne, a bude přednačítat pro každé vlákno inteligentně zvlášť). Netuším, jak je s tím daleko - odhaduji že čím novější jádro (aspoň 2.6.31) tím líp.

Pokud se týče volby FS, většina lidí se shodne na XFS. Je určen pro práci s velkými soubory a dává si záležet na spojité alokaci (brání se fragmentaci). Našly by se i nějaké vady na kráse... to se nedá nic dělat.
Četl jsem zmínky, že EXT2/3/4 nedělá vůbec žádný read-ahead na úrovni FS. Nevím co je na tom pravdy, každopádně i z hlediska generování "nadbytečných seeků kvůli metadatům" není tahle rodina FS zrovna vhodná.
Vycházející hvězdou z hlediska spojité alokace (včetně metadat!) by mohl být BTRFS.

Enterprise disky jsou drahé (cena za kus) a mají malou kapacitu - takže cena za TB je násobně vyšší než u desktopových disků. Budete tedy optimalizovat cenu s ohledem na dvě omezující podmínky: IOps a kapacitu. Kapacita je jasná, potřebná "schopnost IOps" je bez empirických zkušeností s kokrétní zátěží dost těžko přesně spočítatelná

Pokud se týče SATA/SAS, máte pravdu, že desktopové disky mají typicky SATA a enterprise disky mají typicky SAS (dříve SCSI). Jsou ale výjimky: existují (existovaly) "desktopové" disky se SAS rozhraním (nějaké 10k Barracudy) a taky "enterprise" disky se SATA rozhraním (WD Raptor / Velociraptor). V prvním případě vyhodíte peníze za rozhraní, a IOps nebudou o tolik lepší, v druhém případě se traduje nevalná spolehlivost (přestože IOps výborně škálují). Pokud se týče "enterprise" SATA disků Barracuda ES/NS 7200RPM, tak si nějaké vysoké hodnoty IOps radši nepředstavujte

[Jupi]

Pekne rozobrany problem.
Na strankach Adaptec storage advisors su prispevky s dobrou analyzou volby RAID levelov pre rozne typy zatazenia. Tiez ohladom volby radicov, diskov, ... Odporucam.

[Bilbo]

RAID 5 nebrat, je to výkonově nic moc, obzvláště při zápisu malých souborů je to katastrofa. Pokud se má v RAID 5 zapsat jeden malý blok (např. 4 Kb), tak to znamená přečíst starý blok, přečíst blok na disku kde je parita, přepočítat podle toho novou paritu a pak oba dva bloky zapsat. Takže místo dvou paralelních zápisů v RAID 10 (zápis bloku, zápis kopie) jsou tam dvě paralelní čtení, čekání na jejich výsledek a pak teprve zápis.

Bloky v stripu bývají v raidu od 64 KB do 1 MB dle konfigurace, takže všechny zápisu souborů menších než velikost bloku krát počet disků ve stripu na tohle narazí.

Pokud zapisuju toho víc (že to jde přes všechny bloky), tak nemusím nic číst, prostě spočtu paritu a zapíšu vše, ale na situaci, kdy pro zapsání něčeho musím nejdřív nějaký blok přečíst i tak často narazím jakmile dojdu se zápisem na konec souboru.

Proto pokud by to mělo mít problémy s IO, tak místo RAID 5 bych nasadil RAID 10. Stojí to víc disků na stejnou kapacitu (50% disků navíc, oproti jednomu u RAID 5), ale samotné disky nejsou na poli zas to nejdražší a je tam o dost vyšší výkon.

V praxi už dost lidí na pomalost RAID 5 narazila a často to končí přidáním disků a přebudováním pole na RAID 10 :)

[dustin]

Souhlasím, také mám se SW RAID5 nedobré zkušenosti s výkonem. Největší tragédie byl LVM snapshot na SW RAID5, zápis na hlavní oddíl klesl na pár MB/s. Ale je pravda, že jsem neřešil alignment raidu, LVM a filesystému (ani bych to asi neuměl vyřešit :) ). Všude používáme RAID1/10 a v poho :)

[AraxoN]

Ak sa bavíme o serveri pripojenom 100Mbit linkou a serveri, čo bude hlavne čítať z disku a nie zapisovať, tak úzke miesto podľa mňa nebude RAID5, ale tá 100Mbit linka. 100Mbit linka pri najlepšej vôli dá tak 11MB/s, zatiaľčo RAID5 na obyčajných 3.5" SATA diskoch dá čítanie prinajmenšom 5-násobok.

[Ales]

To jsem si myslel take, ale v logu SAR mam v tu dobu 100% vytizeni systemu, coz nechapu. Puvodne jsem si take myslel, schopnost serveru cist data bude rychlejsi nez linka.

A.