Výkon NFS/RAID1/EXT4 žurnálu

[Pavouk106]

Ahoj,

mám následující situaci
Domácí server, na kterém jsou dva disky (typu WD Green, tedy nižší otáčky, vyšší přístupové doby) v softwarovém RAID1. Největší část je formátovaná do EXT4 a exportovaná jako NFS. Ve fstab používám noatime.
Desktop, kde je jen systémový disk a /home se bere z NFS (ze serveru)

Hraju hry ze Steamu, některé jsou ok, jiné se plazí/sekají jako prase. Kdykoliv jde o ty plazící se, tak na serveru svítí LED "aktivita disku" a disky šrotujou co můžou (a stejně nestíhají). Na serveru mi hlásí iotop, že vše stojí na EXT4 žurnálu, kterej má potřebu furt něco dělat. Trochu si myslím, jestli si ty konkrétní hry nerozbalujou nějaký datový soubory (tj. z jednoho 1GB velkýho souboru nedělají milion párkilobajtových). Při kopírování velkých objemů dat v podobě velkých souborů (typicky například video ve vysokym rozlišení) to jede jako po másle (tj. cca 90MB/s, co dovolí Gbit síť).

Cesty kterýma se můžu vydat vypadají z mýho pohledu následovně:
- nehrát ty hry (nejjednodušší řešení, nicméně nejméně chtěné)
- odstavit kompletně žurnál (další z jednoduchých řešení, opět ne úplně chtěné)
- přesunout EXT4 žurnál na jinej disk (mám tu po ruce pomalej 2.5" disk, dává 30MB/s)
- použít jiný FS nad RAID1 (jaký? nebudou stejné problémy?)
- zjistit, co přesně se při tom šrotování děje (nejtěžší věc, protože nemám absolutně páru, jak na to)

Já se přikláním ke zkoušce žurnálu externě. Nemáte s tím někdo praktický zkušenosti?

Pustil jsem si hru Dead Island a už 20 minut čekám na načtení další lokace... (během načítání první/předchozí lokace přetekla nějaká cache, tak jsem čekal "jen" 5 minut)

[Reklama]

[Kolemjdoucí]

Funguje to všechno tak jak má.
Řešení tvého problému je koupit si nějaký opravdický HDD například WD1003FZEX nebo SSD.

[OMG]

ja myslim, ze jsi to vubec nepochopil. pokud se nejaka hra rozhodne, ze bude rozbalovat neco nekam, tak veme treba gigovy soubor a zacne ho cist z NFS a zapisovat na to same NFS po siti. Z toho se tve green disky proste poserou a nedelaji nic jineho nez hlavickami litaji sem a tam. A jelikoz mas zurnal, tak kazdy tvuj zapis generuje dodatecne transakce k zapisu a z toho se zase ty green disky poserou.. Pokud cekas vykon od NFS, zacni solidnim diskovym polem. Pokud se chces hrat, tak proste nemej storage na siti ale nech si jej lokalne na nejakem SSD a budes spokojen.

[Pavouk106]

Kolemjdoucí: Děkuji za věcný názor, příště si ho nech (o výkonu Green disků a jim podobným vím pravděpodobně víc než Ty - čímž netvrdím, že jsou to super nadupaný kousky, to nejsou).

OMG: To čtení a zápis na stejný místo beru, má to svojí logiku. To, že hlavičky kvůli tomu lítají jak splašený, beru taky. Že lítají kvůli žurnálu jako bonus beru taky. A to je to, co bych chtěl zkusit omezit - lítání kvůli žurnálu.

Problém je v tom, že v iotop generuje IO (ne bajty) pouze jbd2 a to ještě tak, že zapisuje řádově desítky kB/s. A jako bonus - ty disky v takový špičce na čtení i další zápisy reagujou normálně (otevřu Operu, normálně si brouzdam, zavřu Operu - to znamená, že začne zapisovat uživatelskej profil, kterej taky neni zadek - a pořád to jede normálně).

S výkonem NFS a RAID1 na těch šunkách jsem celkově spokojenej, ale vadí mi tahle degradace u pár konkrétních her... Většina jich šlape jak švýcarský hodinky, ale Dead Island, Portal 2 a Killing Floor nejedou (ale Portal 1 třeba v pohodě...)

Nemá někdo zkušenosti s žurnálem na jiném disku? Návod si najdu, jde mi jen o to, jestli to někdo provozuje... A taky kolik si na to mám vyhradit prostoru... Ani netuším, jak žurnál funguje - jede po souborech nebo po blocích? Může v něm bejt při zápisu 50GB vše nebo jen poslední/nezapsaný bloky?

[dustin]

Chce se to přes iostat na serveru podívat, jak moc jsou ty disky v takové čekací pauze zatížené.

[Reklama]

[nextsux]

Tim, ze to mas po siti, mas zjednoduseny debug. Vzal bych na to NFS tcpdump a podival se, co to vlastne dela. Jestli to dela stovky malych souboru nebo co se vlastne deje. Pokud to delaji jen nektere hry - problem bude v nich. Neco delaji "jinak".

A tam bych zacal. Protoze pokud nevis, co to zpusobuje, je zurnal na extra disku jen strelba do prazdna. Nehlede na to, ze provozujes greeny - tedy jde ti hadam o spotrebu. Tim, ze budes provozovat dalsi 1-2 disky na zurnal vlastne vymazes to, ze mas greeny a mohls tam dat rovnou normalni

Osobne bych se fakt nejdriv podival, co to dela. Treba by pomohlo jen namountovat tmpfs do nejakeho cache adresare.

[Kolemjdoucí]

o výkonu Green disků a jim podobným vím pravděpodobně víc

Když to tak pěkně víš, tak proč se ptáš někde na fórech ? Proč si jednoduše neodpovíš sám sobě ?

[Lol Phirae]

Tak vědět o výkonu je prima, nicméně ta šunka se do RAIDu vůbec nehodí hlavně kvůli domršenému firmwaru bez TLER, při jakémkoliv problému se čtením z toho RAIDu vypadne.

[RDa]

Rekl bych ze je problem v NFS - green disky provozuji (Raid5, 4 resp. 6 disku) a zadny vykonnostni propad to neni - ostatne neni proc, kdyz na gigove siti NFS jede jak snek:

PC -> write -> nfs -> raid = obcas i 2-3 nekdy 5, bezne cca 10MB/s - podle nalady
raid <- read <- nfs <- PC = 35-40 MB/s konstantne

Takze zda tazatelovi dela hra zapisy, muze zjistit pres strace na hru.

[RDa]

Tak vědět o výkonu je prima, nicméně ta šunka se do RAIDu vůbec nehodí hlavně kvůli domršenému firmwaru bez TLER, při jakémkoliv problému se čtením z toho RAIDu vypadne.

Typicky priklad marketingem zmasirovaneho blba. TLER zaruci jen hlaseni chyby v definovanem case (typicky 7 sec). Disky ktere TLER nemaji se snazi v pripade chyby media cist "nekonecne dlouho". Jak pak muze takovy disk "hned" vypadnout? Disk jez by pri chybe vracel ihned chybu je totalne nepouzitelny (i disk se zapnutym TLER z vyroby, tj. omezenym casem pro opakovane cteni je nevhodny pro desktop).

V pripade, ze disk TLER neumi, se chyba detekuje po 10 az 20sec v zavislosti na vyrobci radice. Linux to vzda po 30sec by default, ale muzete si to zmenit pres /sys/block/$DISK/device/timeout - pokud tam nastavite 5 vterin, muze se to chovat jako TLER.

Je tu ale velke "ALE" - md (sw raid) v linuxu se vam nebude snazit lhat, ze je vse v poradku kdyz vlastne neni (jeden z disku blbne), takze TLER nepotrebuje a ani by ho nevyuzil. A ze to takto funguje jsem velice rad - kazdy vypadek disku z pole je totiz znamkou toho, ze je neco spatne (casteji narazim na chyby v konektorech, kabelech nez poruchu media) a ze je to treba resit. Idealni je pak provozovat pole s write-intent bitmap a zkusit dat disk zpet, synchronizace bude behem chvilky. Jestli to bude vypadavat casto - musite to resit.

Pokud naopak nasadite TLER + HW radic, ktery vam bude maskovat cteni z chybneho disku pres dopocitavani z ostatnich, tak se muze stat ze jednoho dne se sejdou chyby na stejnych sektorech a o data prijdete, aplikace vam spadne. TLER je jen snaha vyrobcu chytre zamaskovat jejich klesajici kvalitu - doufajic, ze uzivatel si nakoupi nekolik disku a tyto se vzajemne zachrani, ze nebudou mit chyby na stejnych mistech. Disky s TLER je tedy mozno vyrabet s nizsimi naroky na kvalitu (chyby jsou priznane).

[Pavouk106]

dustin: Zkusím to večer.

nextsux: Kvůli ceně. Měl jsem je už předtim, neni to žádná bomba, ale stěžovat si taky vysloveně nemám proč. S tím tmpfs jsem to nějak nepobral.

RDa: strace na hru taky zkusím. Zápisy zjevně dělá (jbd2 jede v iotopu IO na 99%), protože jakmile hru killnu, je naprosto klid. V ps vidím u jednoho z nfsd a jbd (možná ne jbd, ale prostě u žurnálovacího procesu) jako status "D", což by mělo bejt čekající na IO. Divný je, že to nezasekne práci s diskama kompletně, normálně se s tim dá dál fungovat... Jinak čtení a zápisy sekvenčně na tom letí krásně (NFS, RAID1, pomalý disky). Kdyby to bylo lokálně, pojede to přes 100MB/s, po síti je to omezenější, ale ne zas o tolik. Ale mluvím stále o sekvenčním zápisu velkých souborů.

Zkusim rozbalit kernel a uvidíme, jak si to povede... Jednou pěkně lokálně z RAID na RAID a podruhý jako bonus přidáme NFS... :-)

[Jimm]

Jeste si zive pamatuji to vlakno, kde jsem psal: "Pavouku, bude se ti to srat a na hry to po siti proste neni". Ale komu neni rady, tomu se ucho utrhne...

[Pavouk106]

Jimm: Jsem rád, že ses ozval :-) Hele, hrál jsem řekněme 50 Steam her a nějaký ve Wine. Vše v pohodě, jen tři kusy zlobí. Tenhle poslední ale ultra moc. Když čekám na načtení půl hodiny, nejde to. Killing Floor se načte rychle, ale pak se seká během hry (donačítává) a Portal 2 je něco mezi těma dvěma... Ostatní šlape krásně, případně se to škubne při donačítání textur jakmile naskočí obraz a pak jede.

V základu jsi ale měl pravdu.

Uši mám obě :-) Život je o kompromisech, někdy se to dá udělat i bez nich, ale já si vždycky sám na sebe něco vymyslim...

[trubicoid2]

a co kesovat nfs lokalne? to by melo zrychlit zapis, ted uz je to nejakou dobu v kernelu

http://xmodulo.com/how-to-enable-local-file-caching-for-nfs-share-on-linux.html

u nfs si jeste muzes hrat se sync/async, rsize/wsize, jumbo packets atd.
to by mohlo trosku taky pomoct, koukni treba tu:

http://www.slashroot.in/how-do-linux-nfs-performance-tuning-and-optimization

[Pavouk106]

trubicoid2: Díky, mrknu se na to. Ten druhej odkaz jsem už viděl dřív, když jsem NFS nastavoval, o lokální cache jsem ale neslyšel.