Dotaz: Write cache pre Sambu

[/dev/random]

Asi to bude blbost ale neexistuje nieco ako write cache pre SAMBU ? Priklad: kopirujem na samba server 50GB súbor a zacina na 100MB/s po case klesne na 80MB/s a skonci to na 50MB/s a prisiel som na to ze to bude chyba diskov na serverovej strane, proste nestihaju zapisovat poziadavky SAMBA serveru. A chcelo by to napr. dat 500GB SSD ako cache pre zapis/citanie z ktoreho by si brala udaje SAMBA podla potreby. Je to mozne ? Alebo proste dat SSD ako cisto UPLOAD share ?

Odpovědi

[Max]

Asi jedině přes bcache, lvmcache apod.
Zdar Max

[frr]

To se Max skromně zapomněl pochlubit, že se o tom na Ábíčku minimálně jednou dost výživně debatilo. Já to čtu až teď zpětně a musím smeknout.

Vnímám rozdíl mezi perzistentní cache na SSD, a případně volatilní cache v RAMce. Oni SSDčka jsou IMO taky dodnes docela svině, jejich schopnost pobrat náhodný zápis je omezená a jejich životnost při random write zátěži není zrovna hvězdná.

V té debatě padl taky názor, ke kterému jsem nezávisle došel i sám, že rozdrobené náhodné zápisy v podstatě moc nejde zrekombinovat do "skoro sekvenčního" zápisu tak, aby to mělo vliv na průchodnost při zápisu na točivý disk. Prostě ten náhodný traffic bude i po setřídění natolik rozházený, že to disku reálně moc nepomůže optimalizovat seeky. Další věc jsou zápisové bariéry (které možná ani nejde v konfiguraci vypnout) a tu rekombinaci v případě RAM-based cache zrovna bariéry dost hatí. Podotýkám, že u točivých disků má na účinnost rekombinace dost zásadní vliv, jestli jsou vespod točivé disky "desktopové" (za starých časů PMR Barracuda) nebo "serverové" (Cheetah). Serverové disky totiž škálují IOps při před-třídění náhodných seeků o něco líp. Běžný desktopový disk umí cca 75 random IOps, při před-třídění náhodných zápisů jsem pozoroval něco pod 180 IOps. Enterprise disk začíná na 170 IOps, ale pokud mu frontu před-třídíte, dostanete se někam na 600 IOps. Ta horní čísla jsou při hodně dlouhých frontách (10k náhodných transakcí napříč celou plotnou). Per spindle, na točivý disk. Je to zajímavé škálování, ale pořád je to žalostně málo, žeano... Ale může to být nakonec i víc, než kolik dává SSDčko, kterému jste už udávili volné místo v interní flash-based write-back frontě.

Tzn. závěr pro mě je, že pokud řešíte ustálený tok skutečně náhodných zápisů, kdy si storage subsystém ani na chvilku neoddechne, tak Vám write-back cache nijak výrazně nepomůže - protože reálně nemá možnost, "odložit zápis na později, až přijde hluchá chvilka". Prostě potřebujete přiměřeně velký počet jednotlivých disků a nejlíp se vyhnout RAIDu, snad kromě RAID 1 nebo 10, pokud lze zároveň splnit kvalitní rozložení IOps zátěže mezi jednotlivé disky. Nakolik se to dá v dnešní době řešit SSDčky, to už nedokážu posoudit. A jakými SSDčky. SLC se v mainstreamu už prakticky nevyskytuje, vyskytují se MLC našponovaná všelijakými triky, nově je k dispozici 3D-Xpoint...

Pokud se nebojíte žít na hraně, a potřebujete tu a tam zapsat sekvenčních 50 GB opravdu střelhbitě, zkuste si pořídit hodně RAMky (64 GB se dá dneska nacpat i do desktopového motherboardu) a poladit parametry dirty/writeback proměnných v /proc/sys/vm. Defaulty jsou totiž nastavené tak, že se RAMka pro write-back cache prakticky nevyužívá. Historicky jsem k tomu něco ublognul... už na to trochu sedá prach. Každopádně závěr tehdy byl, že ani při absenci bariér (syntetická zátěž; reálný zápis souborů tohoto luxusu nepožívá) se v Linuxu nejde obejít bez nějakého timeoutu, kdy nakonec přece jenom "spadne klec, pohár trpělivosti scheduleru přeteče, tříděná fronta degraduje na FIFO a všecko to jde do háje". Přestože típnete generátor zátěže, počkáte si třeba několik desítek minut / hodin / dní, než se velká RAM-based WB cache zapíše na plotny...

[frr]

Hergot... zmotal jsem toho trochu moc dohromady. Motám do toho náhodný zápis, což není Vaše situace. O tom se debatilo na uvedeném odkazu v abíčkovém blogu...

Samozřejmě že pokud do RAM-based WB cache nasypete 50 GB sekvenčně, tak se pak téměř sekvenčně nasypou na disk, to je ještě velmi příjemná situace - vlastně ideální scénář. Dobře by se to uplatnilo např. v situaci, kdy server se většinu času nudí, má 10Gb Ethernet a jenom jeden točivý disk (nebo mirror) takže úzké hrdlo je v přístupu na disk.

[NN]

write cache size = 2097152

[Peter Golis]

Ako, že by nastavil v konfigurácii samby 50GB pre každý súbor? To znie dobre, ale išlo by to na úkor Disk Cache v RAM ktorej toľko nemá.

[frr]

BTW o jak rychlém Ethernetu se tady bavíme, a o jakých discích? Pokud to je výsledek pro 1Gb Ethernet a jeden točivý disk (nebo mirror), tak jsou to ještě docela důstojné hodnoty. Fakt je, že dnešní levné disky začínají na začátku plotny sekvenčně řádově okolo 200 MBps, ale to je bez režie filesystému. A ke konci plotny (na vnitřním okraji) sleze sekvenční rychlost klidně na 40 %, na blokové vrstvě, bez "odskoků mimo pořadí" kvůli metadatům.

Pro jednoho klienta, který má celý server pro sebe, mi to přijde jako ještě docela zdravý výsledek. Pokud byste měl takových klientů současně několik, půjdou ta čísla klidně ještě citelně dolů.

Schválně zkuste nástroje jako top, iostat, latencytop. Nejspíš zjistíte, že smbd se fláká ve stavu "waiting" (čeká na dokončení IO), celý CPU je převážně idle, jenom disk se točí co může.