Dotaz: Koľko pamäte pre rozsiahly filesystém

[AraxoN]

Zdravím.

Postavil som fileserver so štyroma 2TB diskami v softvérovom RAID5. Výsledná kapacita je 6TB. Výkon jednotlivých diskov je OK, výkon poľa pri zápise veľkého súboru tiež (187 MB/s). Keď ale vytváram populáciu testovacích dát, tak výkon postupne klesá a klesá, až sa dostane na nepoužiteľné hodnoty a vytváranie nedobehne ani za 24 hodín.

Ako problém som identifikoval nedostatok RAM. Momentálne tam je len 2GB a väčšinu z nej po chvíli obsadia buffers:

atlas ~ # free
             total       used       free     shared    buffers     cached
Mem:       2042540    2000016      42524          0    1704044      14188
-/+ buffers/cache:     281784    1760756
Swap:      2987516        760    2986756

Testovacie dáta sú tvorené asi 9 miliónmi súborov, rozdelených po adresároch do dvoch úrovní: dir1/dir2/files, pričom dir1 je číslo od 1 do 18, dir2 číslo od 1 do 256, a v každom z nich je asi 2000 files. T.j. na prvej úrovni je 18 adresárov, na druhej 256 adresárov (v každom z tých 18-tich) a na tretej 2000 súborov (v každom z tých 256). Testovacie dáta majú spolu 3 TB (obsadenie filesystému na 50%).

Skúšal som to na ext2 a ext3, chystám sa vyskúšať aj ďalšie filesystémy.

Hardvér je: HP ProLiant DL160G6, 1x CPU E5506, 1x 2GB RAM, 4x HP 2TB 3G SATA 7.2K 3.5"

Je mi jasné, že bude potrebné dokúpiť ďalšiu RAM, otázka ale je, že koľko? V ideálnom svete čo najviac, ale v reáli keď dáme všetky peniaze na pamäť, môžu nám potom chýbať inde. Preto sa na Vás obraciam, či niekto nemá skúsenosť s takto obludnými oddielmi a rozsiahlou populáciou súborov. Neexistuje nejaký vzorec, podľa ktorého by sa dalo vypočítať, že pri počte súborov X bude potrebná RAM najmenej Y ?

Budem ale rád aj za iné návrhy, či pripomienky.

Vopred vďaka.

AraxoN

---

---

Odpovědi

[Kit]

Než začneš dokupovávat další RAM, zkus další filesystémy. Například XFS, ReiserFS, BtrFS, ZFS. Také si zkus RAID10. Podle mne by ta RAM měla stačit.

Některé filesystémy zvládají RAID ve vlastní režii, další mezivrstva tedy nemusí být.

[Lol Phirae]

No tak zrovna ZFS bych s tímhle množstvím paměti rozhodně nezkoušel!

[AraxoN]

Mám v pláne postupne vyskúšať všetky FS so stabilnou podporou v jadre. Aj pred doplnením RAM, aj potom. Mám na to pripravenú tabuľku v OO.org, kam prídu výsledky meraní, aby som vybral najlepší FS pre moje účely. Bohužiaľ momentálne som sa zasekol na tom, že len jedna operácia trvá dlhšie než som ochotný čakať (>24h). Ak sa mi to podarí dokončiť, môžem to sem potom hodiť.

[lertimir]

souhlas. Na FreeNAS dokumentaci (což je freeBSD s konfigurací na NAS a primární podporou ZFS) píšou, že pro větší datové struktury je použitelné minimum 8GB paměti.

[AraxoN]

Tak s Reiserom to zbehlo za 9 hodín a 21 minút. Idem skúsiť niekoľko benchmarkov...

[ewew]

Skús zistiť PID procesu ktorý vytvára tie súbory. Potom vojdi do adresáru /proc/PID/. Skontroluj súbor limits,status. V prípade, že spúšťaš úlohu pod ID väčším ako 0, tak sú tam určité limity.

Hlavne treba sledovať výpisi čo dáva program a sledovať systempvé logovacie súbory. Potom sa možnu bude dať určiť ďalší postup.

[AraxoN]

Robím testy zatiaľ pod root-om, takže limity tam nie sú. Je to ale dobrá pripomienka do budúcnosti, keďže potom na tom bude robiť používateľ nobody.

Skript populate.sh vyzerá takto:

#!/bin/sh

SRC=/root/test_data
DST=/mnt/data

mkdir $DST/files

for i in `seq 1 18` ; do
        mkdir $DST/files/$i
        for j in `seq 0 255` ; do
                echo $i/$j
                mkdir $DST/files/$i/$j
                cp $SRC/* $DST/files/$i/$j
        done
done

[Šangala]

Zkusil bych to i ve dvou etapách struktura a pak data, tedy:
první průběh bez cp $SRC/* $DST/files/$i/$jcp $SRC/* $DST/files/$i/$j
druhý průběh bez mkdir $DST/files/$i a mkdir $DST/files/$i/$j a mkdir $DST/files/$i/$j
…a stopovat to pomocí time.
A to echo bych asi dal o úroveň výš 18 výpisů místo 4608 (nic velkého to nezmění, ale ať to výsledky zbytečně neovlivňuje).

[AraxoN]

Predpokladám, že vytvorenie adresárov zbehne rýchlo. cp-čkom tam kopírujem postupne na 3TB dát, takže tam predpokladám miesto, kde to hapruje. Ale zmenu poradia vyskúšam. Neskôr, pretože teraz mám už populáciu dát vytvorenú a bežia mi tam iné testy a benchmarky. K vyčisteniu FS a novému spusteniu tohoto skriptu sa dostanem asi až zajtra večer.

Pomocou time to všetko stopujem už teraz a zapisujem do tabuľky pre neskoršie vyhodnotenie.

Vypol som crona, aby do toho nezasahoval údržbou (updatedb a tak), aj smartctl, ktorý tam robil short testy diskov raz denne. Okrem toho by tam už nemali byť žiadne nadbytočné démony. Pred každým testom robím umount a mount, čo vyčistí buffers aj cache (odskúšané), aby sa testy navzájom neovplyvňovali. Zatiaľ mi nič ďalšie nenapadá. Test beží, takže ostáva len čakať.

[alkoholik]

Zkus si pustit v dalsi konzoli perf top. Treba neco napovi.

[AraxoN]

Samotné vytvorenie adresárov, vrátane všetkých príkazov echo prebehne za 2.3 sekundy. Je to naozaj až kopírovanie súborov, čo položí toto pole na kolená. Nerozumiem tiež, prečo mu tak dlho trvá príkaz find, alebo du. Veď zjavne je možné cez tie adresáre prejsť za pár sekúnd.

[AraxoN]

Hľadal som aký je rozdiel medzi buffers a cached a podľa všetkého rozdiel spočíva v tom, že do cached ide (okrem iného) obsah jednotlivých súborov. Do buffers idú fyzické bloky, ktoré sú čítané (zapisované) na disk. T.j. pre príkaz cp, je správne že položka cached je takmer prázdna na úkor buffers, pretože cp sa nezaujíma o obsah súboru, ale len o to, aby sa dostal z miesta X na miesto Y.

Z tohto pohľadu teda je to čo som pozoroval v pôvodnom poste pre tento typ záťaže úplne v poriadku. Napriek tomu to ide mizernou rýchlosťou a verím, že viac pamäte by pomohlo. Mám len problém nadefinovať, aké množstvo je ešte rozumné a aké už nie.

Ďalší test som spravil s príkazom find nad týmito dátami a ten teraz trvá 117 minút. Keby boli všetky bloky adresárovej štruktúry (t.j. nie dátové bloky) v buffers, tak by find musel prebehnúť omnoho rýchlejšie. Je možné zistiť, koľko blokov zaberajú tieto meta-dáta na disku aby som podľa toho prispôsobil rozšírenie RAM?

[AraxoN]

Eh, porazí ma! ... zabudol som do mount options dať noatime! Idem začať testovanie odznova.

[AraxoN]

Tak týmto to nie je... Rozdiel medzi rýchlosťou operácií s atime a noatime je iba niekoľko percent (samozrejme v prospech noatime).

[:]

Pro porovnání se můžeš podívat na Synology NAS servery: DS3612xs, DS2411+, DS411j

[AraxoN]

To je hodne zaujímavé - vystačia si s 1 GB na 12 diskov, a so 128 MB na 4 disky.

[Ivan]

Jeste se neco nezmenilo, tak Linux kernel neumi drzet v buffer cache cast inody adresare. Tzn. nezalezi ani tolik na tom kolik mas storage, jako na tom kolik mas souboru v adresarich.

[AraxoN]

V každom adresári je maximálne cca 2000 súborov. Mali sme predtým raz problém, keď sme na starom serveri v jednom adresári nechali okolo milióna malých súborov a server sa zadýchal už keď do toho adresára mal čo i len vojsť. Preto to teraz už delíme na menšie kvantá do podaresárov, čo pomohlo. Toto má byť nový server, takže to ešte len testujem.

[Kit]

To záleží na použitém filesystému. Pokud je založen na B-stromech, tak je mu vcelku jedno, jestli je těch souborů v adresáři dvacet nebo dvacet miliónů.

[Ivan]

Na tom prave zalezi. Samozrejme ze kdyz na normalnim fs (ext3) napises 'ls -l' tak to ma slozitest O(n^2), proste proto, ze adresar je linearni seznam a pro vypsani atributu jednoho souboru ho musis cely projit. Zatimco u B-tree je to jen O(n*log(n)). Porad ale plati, ze musis mit v pameti cely adresar - tzn. cely seznam souboru. Za normalnich okolnosti to neni problem, ale kdyz provozujes maildir pro vetsi mnoztvi uzivatelu tak uz je to znat.

[Michal2]

Kdysi davno jsem delal testy co snese ext2 a mel jsem milion souboru a slapalo to, prochazeni struktury, kopirovani, presouvani- bez znamek zpomaleni. Cely pocitac mel 64 MiB. Na 9 milionu, je li to linearni, by melo postacit pul giga.

[lertimir]

Co Vám ukazuje nástroj iotop? Není ztráta rychlosti na žurnálu?

Zkusil jsem si totéž v menším rozsahu, mám podobný i když podstatně méně výkonný server. (4x1,5TB v raid5, nad tím lvm, nad tím ext4, a poháněné úsporným AMD Zacate s 4GB paměti). Spuštění Vašeho upraveného skriptu dává cca 40-70MB/s zápisu. Oddíl na LVM je celkem zaplněn (přes 2,5 TB dat a cca 500GB volný, proto jsem zapisoval jen 100GB). Přímý sekvenční zápis 1GB souboru

dd if=/dev/zero of=file1G.tmp bs=1M count=1024

mi dává rychlosti cca 130-135 MB/s

[lertimir]

A moje free po 80% běhu skriptu dává

$free
             total       used       free     shared    buffers     cached
Mem:       3607968    3505856     102112          0     173252    3100984
-/+ buffers/cache:     231620    3376348
Swap:            0          0          0

veškeré operace jsem dělal pod běžným uživatelem.

[AraxoN]

Zdravím.

Ext4 som ešte neskúšal, chcel by som teraz nechať prebehnúť všetky testy s Reiserom. Ktorý proces mám potom hľadať v iotope? [kjournald] ?

[lertimir]

podobně jako top je iotop setříděné podle procesu, které mají největší io. Takže zajímavé jsou ty nahoře

V ext4 (a tuším i v ext3) je journal proces jbd2.

[lertimir]

zajímavé je že mám zcela jiný poměr mezi buffer a cached

[AraxoN]

Bude to asi závisieť od FS - s reiserom sa mi to teraz tiež chovalo inak ako predtým s ext2 a ext3.

[AraxoN]

Ďakujem všetkým za pripomienky. Momentálne je objednané rozšírenie na 10 GB RAM a stále bežia benchmarky reiseru.

[lertimir]

Ještě hezký nástroj je atop, který také ukazuje okamžité rychlosti a zátěže jednotlivých fyzických disků pole, rychlost a zátěž raidu i oddílů.

[AraxoN]

Zatiaľ som to pozeral cez dstat - cez -D sa dajú vypísať jednotlivé blokové zariadenia (t.j. cez dstat -D md4,sda,sdb,sdc,sdd vidím všetko podstatné). Atop skúsim.

[linuxik]

Ahoj,

nedavno jsem narazil na podobny problem, a dokoupeni RAM to nevyresi. Musis se smirit s tim ze SW RAID5 navic nad 2TB SATA disky ma pomale IO operace. Pro stream je to samozrejme jedno, ale male soubory znamenaji konecnou. Pokud dokoupis RAM, tak samozrejme posunes prah, kdy diskovy system prestane stihat, ale v realnem provozu stejne nejspise dojde k zaplneni RAM a nakonec to bude pomale. Nez dokupovat RAM radsi popremyslej nad RAID10 a HW radicem.

[lertimir]

Nějak tomu nemohu věřit, ale pokud je to pravda, tak to znamená zásadní a významnou chybu v designu linuxového SW RAIDu. HW RAID má jasný význam v případě, že jsou procesory serveru hodně zatíženy a oddělí tím pádem zátěž na počítání parity na specializovaný HW toho RAIDu, ale pokud je hlavní procesor v podstatě v klidu a nemá co dělat, tak rozpočítání dat do jednotlivých disků musí zvládnout stejně jako specializovaný procesor v HW RAIDu a pokud jsou datové linky na motherboardu nezávislé, tak i s disky musí komunikovat stejně jako HW RAID. Jiná věc samozřejmě bude na zatíženém systému, kdy scheduler nepustí procesor na dostatečné množství úloh na zápis na disk, tak tam zpomalení vůči HW RAIDu bude značné, ale to není případ popisovaných testů. Tam se nic neděje.

[linuxik]

Neni to ani tak chyba SW RAIDU5 jako spis vlastnost Kdyz se nad tim zamyslis, tak RAID5 znamena pro server nejen pocitani parity, ale i 4x duplikovane IO operace, kazdy zapis i cteni(o jednu IO mene) na disk vyzaduje zapsani dat na vsechny disky. Toho te zbavi jen HW raid. Pokud jeste muzes vyzkousej SW RAID10, vykon v IO operacich bude X-ktat vetsi.

ps. jaky si myslis ze je duvod pro kupovani drahych HW raidu i dnes v dobe 8 jadrovych CPU, kdy procesor na beznem serveru ma zatez v jednotkach procent.

[cronin]

HW RAID svoje opodstatnenie má. Predovšetkým tam, kde sú priority výkonnosť a/alebo spoľahlivosť. Akurát je rozdiel, či ten HW RAID je zadrátovaný skutočne v HW, alebo je to len čip s napáleným okresaným Linuxom so SW RAID-om, taký "softvérový RAID na dedikovanom hardvéri" - bežné riešenie napr. u HP ProLiant serverov.

[semtex]

Jen poddotaz: Určitě je lepší hw raid ve spolehlivosti? (Pokud nepočítám odlehčení cpu).

Totiž - jednou jsem měl hw řadič a on po několika letech odešel. No a na jiném řadiči jsem měl problém to pole poskládat zpět. To s mdadm nemám. Klidně vezmu disky z pole do jiného PC, pole nastartuju a jede...

Nebo už jsou hw řadiče dnes vychytanější?

[Lol Phirae]

Ne, nejsou. Ono totiž, pokud si každý řadič ten RAID představuje jinak, bude nutně pole po přemístění na jiný (nekompatibilní) řadič prostě nefunkční. Takže díky, ale fakt nechci.

[alkoholik]

Mas v tom drobatko gulas.
Nedegradovany RAID5 potrebuje na cteni jednu IO operaci, na zapis dve cteci operace (stara data, stara parita) a dva zapisy (nova data, nova parita). Rozhodne se nezapisuje na vsechny disky.

[semtex]

Guláš v tom máš Ty. Když dám příklad - 3 disky v RAIDu5 - tak např. zápis prvního bloku dat vypadá následovně - 1/2 bloku na 1. disk, 1/2 na 2. disk a parita na 3. disk. Takže rozhodně se vždy zapisuje na všechny disky...

[alkoholik]

Cemu tady rikas blok a proc ho proboha pulis?
Pro tri disky je RAID jasny. Blok 1, blok 2, parita pro bloky 1 a 2, blok 3, parita pro bloky 3 a 4, blok 4, atd..
Ty to mas ocividne nejak pomichane se stripem.

[alkoholik]

Odkaz na wiki, kdybys mi porad neveril.
Jak sis vubec predstavoval zapis na RAID5 treba z 12 disku?

[semtex]

Ale vím, jak na 12 disků, 11 bloků a parita... A tak dále a postupně. Ale to mi vážně chceš tvrdit, že se když máš jen jeden tvůj blok, tak se nahraje na 1. disk a na zbylých 11 disků se nenahraje nic, ani parita?

[alkoholik]

A to jsem snad nekde psal?
..a dva zapisy (nova data, nova parita)..

[semtex]

Jo, včera jsi psal - Rozhodne se nezapisuje na vsechny disky. Já tvrdím, že při každém zápisu se zapisuje na všechny disky...

[alkoholik]

A ja zase tvrdim, ze rozhodne ne.
Vsadime se?
Tady to mas animovane. Tebe zajima cast "Problem (write penalty)".
BTW: tohle je ucivo stredni skoly..

[semtex]

No nevím, co to na mě zkoušíš, ale ta část "Problem (write penalty)" je o přepisování jednoho bloku dat, ne o zápisu nových dat... Z dosavadní diskuze podle mě vyplynulo, že se bavíme o zápisu nových dat...

Možná, že tímhle způsobem funguje i zápis nových dat, pokud je velikost zapisovaných dat menší než chunk size, ale vzhledem k bežné velikosti chunk size 64kB je to dost nepravděpodobný...

[alkoholik]

V diskuzi je par dulezitych informaci:
"Kdyz se nad tim zamyslis, tak RAID5 znamena pro server nejen pocitani parity, ale i 4x duplikovane IO operace, kazdy zapis i cteni(o jednu IO mene) na disk vyzaduje zapsani dat na vsechny disky.
a dole jeste "Mdadm mi tam vytvoril default chunky o veľkosti 512k, čo sa mi vidí trochu veľa. Priemerný súbor tam má okolo 20k, len sem-tam sú väčšie".
Ty se celou dobu zamerujes na zapis velkeho souvisleho bloku dat. Jenze zapominas, ze vetsina operaci modifikuje metadata. Vsechny zmeny mtime, atime, velikosti.. Takze casto potrebujes modifikovat malicky 4kb inode.

[semtex]

No po pravdě, celou dobu jsem to bral, podle toho, co psal autor dotazu, tedy kopírování cca 3TB dat... Takže bych to uzavřel, nemá cenu se hádat každý o něčem jiném...

[semtex]

BTW. ta velikost 512k, to je v příspěvku na konci diskuze, toho jsem si nevšiml. Tam si myslím, že pro případ 20k souborů je velikost chunku 512k naprosto v pořádku.

[lertimir]

Tohle platí pouze, když zapisuji méně než celý strip, v tom popisu na wikipedii je to popsáno pro zápis jednoho bloku. Musím původní data přečíst, abych dopočítal novou paritu. A mohu to dělat i sofistikovaněji, třeba v případě RAID5 nad 4 mi disky, ve chvíli kdy do stripu (o velikosti jeden blok) zapisuji dva bloky (třeba na disk 1 a 2) stačí přečíst odpovídající blok z disku 3 ze všech 3 bloku spočíst paritu pro 4 a zapsat bloky do disku 1,2 a 4. nemusím jako v tom prvním případě stejný blok načítat, který musím zapisovat.

A v případě zápisu celého stripu nemusím načítat nic a jen zapíšu do všech disků. Ale tady by mohl být zakopaný pes u tazatele, pokud se mu při vytvoření raidu implicitně vytvořily velké stripy může to mít velmi významný vliv na degradaci výkonu.

[lertimir]

RAID5 znamena pro server nejen pocitani parity, ale i 4x duplikovane IO operace, kazdy zapis i cteni(o jednu IO mene) na disk vyzaduje zapsani dat na vsechny disky. Toho te zbavi jen HW raid.

Jakto, že mě toho zbaví HW RAID. Samozřejmě nezbaví. Protože i on musí 4x zapsat data na disk, i on musí počkat na disky, až se provedou seeky. Při pohledu na datové rozhraní disku není v přenosu rozdíl. Pokud mám kvalitně provedenou základní desku, a tím myslím, že všechny disky mohou jet současně přenosy do paměti v plné rychlosti, které jsou schopny, není naprosto žádný důvod, proč by SW RAID neměl mít stejný výkon jako HW RAID. Jasně pokud je deska jednoduchá a datový proud na jednom SATA vyblokuje datové proudy na jiném SATA, tak je to na RAID nepoužitelné. A právě v jednoduchosti desky může být zrada.

ps. jaky si myslis ze je duvod pro kupovani drahych HW raidu i dnes v dobe 8 jadrovych CPU, kdy procesor na beznem serveru ma zatez v jednotkach procent.

První důvod je rozdělení výkonu. Pro velké raidy visící třeba na Fibre Channel má smysl. A druhý důvod je marketingová politika výrobců, jejich lenost (že nechtějí dělat jinak zpracované zařízení než na jaké jsou zvyklí) a hloupost a lenost kupců (raději dáme dvakrát tolik a bude to jednoduše fungovat než abychom měli práci se seřízením a nastavením).

Je to podobné, jak někdy koncem 80 let se pořád prodávaly minipočítače Digital Equipment VAX xxx. Také jsem slyšel spoustu argumentů, že to je to pravé, když jsem vysvětloval, že pracovní stanice třeba od SUN nebo Silicon Graphics udělá to samé za 1/5 ceny.

[cronin]

Súhlasím s názorom, že dodanie RAM priepustnosť nezvýši, aspoň nie nijako dramaticky. Zatiaľ čo RAID 5 je z princípu veľmi dobrým kompromisom medzi spoľahlivosťou a kapacitou (spoľahlivosť pri výpadku ktoréhokoľvek z diskov a kapacita N-1 diskov), výkonostne je na tom relatívne biedne, najmä pri malom počte diskov. So zvyšujúcim sa počtom diskov výkonnosť rastie, viac sa prejavuje efekt stripovania a potláča sa efekt parity. Od cca 5-6 diskov v poli RAID 5 je už výkonnosť vcelku zaujímavá. Zhrnuté do jednej vety: investoval by som radšej do nákupu dalšieho disku ako do pamäte. Okrem lepšej výkonnosti by som získal vyššiu kapacitu.

Ďalšou a pre výkonnosť kľúčovou je otázka, či je skutočne nevyhnutné mať na celom diskovom poli jedinú partíciu.

[AraxoN]

Debatou o RAID5 vyššie ste ma inšpirovali ku myšlienke, či moje problémy nesúvisia s veľkosťou chunkov v tom RAID5. Tak som trocha googlil a povedal by som, že na tom niečo môže byť:

• Chunk size: the hidden key to RAID performance
• RAID, chunk size, and ext2 filesystem

Mdadm mi tam vytvoril default chunky o veľkosti 512k, čo sa mi vidí trochu veľa. Priemerný súbor tam má okolo 20k, len sem-tam sú väčšie (to potom majú mega a viac). Ja budem od toho potrebovať veľa náhodne rozložených I/O prístupov, hlavne ku tým malým súborom (jedná sa o náhľady, maličké obrázky).

Skúsim teda menší chunk size. Taktiež skúsim poskytnúť informáciu o veľkosti chunku filesystému - pre ext3 cez tune2fs, pre iné FS musím zistiť ako.

[trubicoid2]

tak ted je default 512k? driv bylo 64k a ja si udelal 256k

ale jestli mas stredni soubor o 20k a 4 disky, z cehos 3 s datama, tak 20/3 bude spis optimalni chunk kolem 8k

no a vyzkousej xfs, nemusi se mu nic rikat, vsechny parametry sam z md urci

[AraxoN]

Včera som tam dal vyrobiť md s chunkom 32k, v noci sa to synchronizovalo. Ráno som vytvoril ext2 s parametrami podľa toho druhého odkazu, plus som pridal žurnál (t.j. ext3). Populate.sh zatiaľ podľa dstat-u zapisuje okolo 60MB/s, čo je o dosť lepšie než predtým (vtedy dával asi 13MB/s).

[lertimir]

Nemyslím, že se dostanete o moc níž. Podle mne hlavní brzda je počet operací, které se udělají s diskem. Seek time na 7200 otáčkovém disku je typicky 8,9 ms to znamená na takový HDD se nedá udělat typicky více než 100 náhodných přístupů (čtení/zápis) za sekundu. Pokud na malých souborech je třeba 2 operace na disku na zápis a ještě je třeba zapisovat do inode kde je soubor. Takže pro malé soubory to bude někde kolem cca 50 souborů za sekundu. Samozřejmě NCQ a buffery něco zlepší, ale u těch raidů to nemusí být moc. (já mám chunk na 16k). A nevím jestli je nějaká zásadní nevýhoda udělat chunk hodně malý např 1 kB.

[x]

Ja bych vrele doporucil jit do http://www.dragonflybsd.org/release30/ na 64bit kvuli Hammer FS a misto ram prikoupit SSD pro swapcache http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache§ion=ANY

Benchmarky jsou nejake v man, daji se najit i v archivech mailing listu pripadne v jejich magazinu a taky neni nad prakticky test. Celist zustane otevrena hodne dlouho

ext2/3/4 opravdu ne moc vhodne na podobnou zatez, to uz je lepsi FFS/UFS, ZFS je otresny zrout a pokud by jste uvazoval nad deduplikaci, tak to si kupte rovnou i fabriku na vyrobu pametovych cipu (:D), btrfs mozna za par let, ted predpokladam, ze chcete neco overeneho.

Jinak na tyhle benchmarky je stale nejlepsi Dtrace kde clovek vidi proc neco tak dlouho trva, bohuzel na Linuxu je jen v Oracle Linuxu, pak je to v OpenIndiana/Illumos/SmartOS ale nejlepsi implementace mimo Solaris-like je v FreeBSD

[x]

Kdyby se nekomu nechtelo hledat, tak napr. tady Dillon's benchmark (upozornuji, ze to je cca 2 roky stare a ted uz je vykon mnohem dale a pri pouziti SSD swapcache by find v te dobe na 9 milionech souboru trval cca 1 minutu )

Jinak benchmarky se daji najit tady dbsdlog nebo v Mailarchive

[AraxoN]

Myslím, že túto otázku môžeme uzavrieť.

Všetkým Vám ďakujem za rady, pripomienky, podnety. Moja otázka bola položená zle - nie je to otázka množstva RAM, je to otázka toho, že sa musí vedieť ako to nastaviť. Jednoduchou úpravou chunk size RAID5 a poskytnutím tejto informácie pri vytváraní FS sa všetko výrazne zrýchlilo.

Doteraz som zo sw RAID-u používal len RAID1, preto som sa s týmito pokročilejšími nastaveniami nepotreboval zaoberať. RAID so strippingom som doteraz nechával na špecializovaný HW. Zjavne som predtým vždy mal šťastie, že to fungovalo dobre aj bez môjho "ladenia".

V pondelok majú prísť RAMky, potom začnem testovať jednotlivé filesystémy odznova, aby výsledky boli za rovnakých podmienok a dali sa navzájom porovnať. Plánujem výsledky potom hodiť sem.

[x]

proc je mirroring porad nej