Administrace komentářů

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