NFS nagy teljesítménnyel

Red Hat, Fedora, CentOS

hali,

kis webkiszolgáló cluster, egy központi géppel, amin NGINX és NFS fut, két appszerverrel, ahol php-fpm, és egy db szerver (az az NFS közelébe sem szagol, és rendben is van ott minden). eddig oké, pacemaker/corosync cluster glue-val fut az egész. azzal a résszel nincs is probléma.

a bottleneck az NFS.

jelenleg ezek a mount opciók a kliensgépeken (/proc/mounts):

clusterhead:/home/ /home nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.xx.xx,minorversion=0,local_lock=none,addr=192.168.xx.yy 0 0

(lock nem is kell (más módon van megoldva), az async módot meg nem merem bevállalni, mert rohadt fontos az írási integritás.)

helyenként 80-100as loadba is befutnak ezek a kis gépek. munin gráfokon megnézve, a gond az, hogy a proci(k) kurva sok időt tölt(enek) iowait állapotban az appszerveren. a vmstat alapján is ez a helyzet, ott is az i/o sleep dominál. egyértelmű, hogy az NFS szerver nem bírja a rohamot.

kicsit lejjebb vettem a php-fpm-ben a futó processzek számát, javult is a helyzet, plusz az NFS szerveren a kiszolgáló processzek számát felhúztam 32-re (/etc/sysconfig/nfs):
RPCNFSDCOUNT=32

de változatlanul eléggé nagy az iowait, a load is ugrál. szóval kéne valami megoldás. :/

ami még gyanús, az a netstat grafikonon a failed és a resets nagy száma.

a grafikonok: http://www.pdx.hu/jobs/nfs/

ami eddit volt és lesz:
- a sysctl.conf-os performance tuningokat már rég megcsináltam, nem ott lesz a gond szerintem.
- eddig egy HDD volt a clusterhead-ben (az NFS szerverben), most az NFS megosztás (a /home/) kap egy sajátot ma éccaka.
- az NFS processzek számát feljebb vettem.
- a php-fpm processzek számát lejjebb vettem, hogy kevésbé terheljék a rendszert.

ami gyanús:
- az rsize és a wsize kurva magasnak tűnik nekem (rendszer default értékek).
- ellenőriztem, az interfészek mindenütt 1Gbit módban vannak. az MTU 1500. vegyem feljebb?
- mivel lokális net a cluster, esetleg felejtsem el a TCP módot, és váltsak UDP-re, sokkal alacsonyabb rsize/wsize-al?

ötletek?

( fonya | 2014. 07. 31., cs – 20:56 )

Hasonlo gonddal kuzdok en is, bar kisebb terheles mellett, ha van megoldas, erdekelne :)
Nalam tcp modban, gigabiten, jumbo framekkel (is probalva), es hardweres raid10-en van az nfs.

Igen, lenyegeben mtu.
Aktualisan anelkul megy, mert nem tapasztaltunk kiugro sebesseg novekedest, a howto, amit alapul hasznaltunk az nagyjabol ez volt:
http://nfs.sourceforge.net/nfs-howto/ar01s05.html

Illetve egy normal/jumbo frame "osszehasonlitas":
http://www.boche.net/blog/index.php/2011/01/24/jumbo-frames-comparison-…

Most mar akademiai a kerdes, de erdekelne a megoldas.

( gedez | 2014. 07. 31., cs – 21:20 )

Az NFS szerveren mi látszik? IO wait, esetleg swap?
Az NFS-en hogy van mount-olva a hdd?

A kiszolgálók milyen paraméterekkel rendelkeznek? CPU, RAM?

Nálam UDP-vel megy, és bírják rendesen, van amikor NFS egyik node felé 3-400Mbps-ot tol, és iowait-en nagy megingás sem látszik ilyenkor. A kliensek sem kicsik, van bennük rendesen memória is, és az NFS-t sem 1 HDD szolgálja ki.

na, akkor sorban:
- swap a kiszolgálón letiltva. ha 16GB nem elég neki, akkor fulladjon bele. :)
- IO wait viszont magas, majdnem egy procinyit elvisz (softirq minimál)
- mountolás:
/dev/mapper/vg_angua-lv_home /home ext4 rw,noatime,barrier=1,data=ordered 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
- /etc/exports:
/home 192.168.80.0/255.255.255.0(rw,sync,no_root_squash)

a clusterhead: core i7 4 magos, 16GB ram, SATA3 HDD (eddig egy, ez bizonyosan szűk keresztmetszet, ma éjszaka kap egy külön hdd-t a /home)
az appszerverek: core i3 2 magosak, 8GB ram

és hol bírnám az NFS-t UDP-re állítani? és olyankor mi az ajánlott rsize,wsize, egyéb paraméterek?

Ahogy írtad, lock nem kell, mert plussz írás, data=writeback, journal_async_commit, commit=600 a kiindulási oldalon jó lehet, udp-vel próbáld TCP helyett, több kicsi lemezt tegyél alá raid10-ben és/vagy SSD alapú cachet húzz fölé, mondjuk dm-cace/flashcache..., vagy térj át SSD alapra tisztán

Szerintem kevés: keresik, hogy mitől lassú. És ehhez lehet köze a hálózatnak is.
De látod, itt is csak az arcod méretével dicsekszel (röhögteted ki magad), ahelyett, hogy segítenél a kérdezőnek. Pedig te mindenhez értesz, ugye? :D

Ui: rsize, wsize méretére tud valaki érdemi magyarázatot? Ami leírást láttam (régi lehetett, manapság lehet, hogy érvényét vesztette) , abban azt írták, hogy a MTU közelében illene lennie, de jumbo frame használata esetén is max. 9000.
Google találat volt, még arra sem emlékszem, hogy doksi vagy blog poszt, szóval akár marhaság is lehet.

Upd: http://www.tldp.org/HOWTO/NFS-HOWTO/performance.html úgy tűnik, az a 9000 byte hülyeség volt, viszont az 1MiB -t továbbra sem értem.

hát ráadásul ez még nfsv3-hoz készült, én meg v4-et nyomok (ezért is van tcp-n defaultból).

viszont mivel abszolute lokális hálóról van szó, ezért gondolom, hogy a tcp kicsit overkill. kipróbálom udp-n (ha végez a fránya másolás), oszt ha jó, akkor úgy hagyom, ha meg nagyon felmegy a retransmit, akkor visszarakom tcp-re (bár jó eséllyel akkor is csak megkímélem magam a látványtól, tcp layerben attól még mehet a csomagpakolgatás...).

elgondolkodtam a jumbo frame-en, aztán úgy döntöttem, hogy az annyira nem segítene, tipikusan kicsi fájlokat ír és olvas nagy elánnal.

ez az 1M-s rsize és wsize nekem is rejtély, semmilyen (még nfsv4) leírásban sem találkoztam ekkora értékkel. hogy a nyomorba lett ez a centoson a default? O_o visszavettem 32k-ra.

( NagyZ v | 2014. 07. 31., cs – 23:03 )

nem az NFS a szuk keresztmetszet, csak szegeny nyomorult HDD ennyit tud. vegyetek ala RAID10-es SSD tombot (4x800GB Intel S3700, 1TB Samsung 850 v 845DC v 840Pro, igenytol fuggoen)

azért az SSD-től fázok egy ilyen feladatra. az appserverekben az van boot és system drive-ként (nem akartam szórakozni PXE-vel meg utána azoknak az update-elésével -- tudom, lusta vagyok --, plusz nem akartam azzal is terhelni az NFS-t -- így utólag jó ötlet volt), de ezek a share-en speciel baromi sok kis írás történik, és az ssd azért a random access perf-en kívül nem tud akkora nagyot szakítani ilyen írási pattern mellett. az élettartamról nem is szólva.

bár lehet, hogy hülyeségeket beszélek, az tény, hogy éles szervertapasztalatom az nincs ssd-kkel.

Rosszul tudod, az XFS tipikusan a nagy méretű fájlok kezelésében jó.

Az SGI nagy teljesítményű 64 bites naplózó fájlrendszere, amit eredetileg IRIX-hez fejlesztettek, de később portolták Linux-ra is, illetve FreeBSD-n is elérhető csak olvasható módban. Különösen hatékony a nagy fájlok kezelésében és a kiegyensúlyozott adatátvitelben.

Illetve mivel csak metadata journalingot használ, nem viseli jól az unclean shutdown-t.

Én speciel semmi alá nem ajánlanám. Nem mostanában volt, hanem 2010 körül, de az akkori tesztjeimen nagyon csúnyán alulmaradt az ext4-gyel szemben: tar xzf linux.tar.gz, sync, majd rm -rf, ennyi volt a feladat. Az rm -rf futási sebességében konkréten kb. háromszoros eltérés volt az xfs hátrányára.

nem kell felni az SSD-ktol, nem tudom pontosan mit ertesz "random access perf" alatt, mert ilyen nincs, maximum latency illetve throughput adott blokkmeret mellett, de ezeket kar osszemosni.

nekem uzemel teljes SSD storagem ~1 eve gond nelkul, diszkenkent <20TiB writenal jarunk (x32 diszk) (a gyari TBW erteke 240TB), ha nem az olcso, kicsi kinait veszed, tokeletes lesz. fent irtam mar, hogy milyeneket vennek, bar szerverbe en Intel parti vagyok.

de ezek a share-en speciel baromi sok kis írás történik, és az ssd azért a random access perf-en kívül nem tud akkora nagyot szakítani ilyen írási pattern mellett. az élettartamról nem is szólva.

bár lehet, hogy hülyeségeket beszélek, az tény, hogy éles szervertapasztalatom az nincs ssd-kkel.

Masszívan hülyeséget beszélsz! A baromi sok kis írásra pont az SSD való. Természetesen RAID1-ben, mert az SSD nem örökéletű.

Az SSD kiválasztásánál pedig pont az IOPS adatot kell nézni a specifikációjában. Aminél ezt basznak megadni, azt nem kell megvenni.

A diszkek 75-210 IOPS-t tudnak, 210-et a 15K-s diszkek. A legalja consumer SSD-k 8-10 ezer IOPS-t tudnak, de egy OCZ Vertex 3 (ami ugye előző generációs, 20 ezer forintos consumer termék) 60-70 ezer IOPS-t tud. Sok kicsi IO műveletnél pedig ez az egy érték, ami fontos. Szóval nem biztos, hogy annyira baromira drága kell legyen az az SSD.

Nagyjából igaz, de az SSD-k sem képesek folyamatosan tartani a random írás IOPS-t. Lehet, hogy az első 2-3 GB írás menni fog 90k IOPS-szal, de utána leeshet 10k IOPS környékére, egyes típusoknál benézhet 1k IOPS alá is (sőt ad absurdum 100 IOPS alá is, de ezek remélhetőleg lassan kikopnak már a piacról). Sajnos a gyártók ezt az aprócska részletet el szokták sunnyogni az adatlapon.

Anandtech-en szoktak IOPS consistency mérést csinálni, szép grafikonon látszik, hogy melyik mennyire jó tartós terhelés közben. És így nézve már általában igaz az állítás: eléggé megkérik az árát az olyan SSD-nek ami folyamatosan is tartani tudja a magas IOPS-ot.

Persze ez nem akkora tragédia, mint elsőre látszik, csak tudni kell, hogy a terhelés nagy átlagban mennyi lesz. Ha alapvetően rövidek a burst-ök, akkor az üresjárati időkben lesz ideje az SSD-nek összeszedni magát, és a gyakorlatban nem találkozol belassulással. Persze vannak kontrollerek, amik nem igazán szedik össze magukat, még trim után sem, a Sandforce (pl az említett Vertex3-ban) tipikusan ilyen.

Másrészt bizonyos típusok (de szintén nem mind, lásd rossz példának megintcsak Sandforce) jól reagálnak arra, ha fenntartasz szabad területet, így némi tárhely beáldozásával tudsz javítani a teljesítményen.
---
Régóta vágyok én, az androidok mezonkincsére már!

Az 1 GBit/s (128 megabájt/s) sebességet elosztod az NFS jellemzően 4k-s blokkméretével. Tudom, hogy a full dublexnek ez csak az egyik fele, de nem számoltál egy csomó dologgal (nem lehet 100%-ra kitömni, a csomag újraküldések csak 1x jutnak el a diszkig, az nfs/udp headerek és checksumok csökkentik a hasznos sávszélességet, a cache-ben levő adatokat sem a diszk szolgálja ki, stb.), szóval a 30k erős felső becslés.

A vmware-nek vannak anyagai ezzel kapcsolatban, a hogyan lőjük össze netapp nfs-sel részben. Ott gigabites ethernetenként maximum 12500 IOPS csúccsal számolnak.

Ezért mondtam, hogy nem akkora tragédia, elég alaposan meg kell küldeni, hogy ez a probléma kijöjjön. De típusfüggő, pl a sandforce egy komolyabb random write terhelés után többet soha nem tér vissza az eredeti teljesítményhez, még teljes trimmelés után sem. Csak secure erase-zel lehet visszahozni, az meg nem túl nyerő.

Egyébként BTW: a számítás a másik irányban is elhanyagol dolgokat. Pl a lokális fájlrendszeren lesznek metadata update-ek, journal irások is, amik az NFS-en nem jelennek meg külön műveletként. Vagyis lehet, hogy 1db kis write NFS-en egy fájlba, 3-4 block write-ra fog leképződni a diszken. De ez elég extrém eset (write combining nélkül folyamatosan kisblokkos append a fájl végére, közben folyamatosan syncelve).
---
Régóta vágyok én, az androidok mezonkincsére már!

Mondjuk nem tudom, kellett-e valaha méretezned hardware-t jó előre mindenféle érdemi információk nélkül, ott egy ilyen számolás már egész jó :) Mikor utoljára összeszámoltam egy ilyet a mindenféle okos igények mentén, akkor mondtam a főnöknek, hogy szerintem egyszerűbb, ha megveszünk valami kisebb storage gyártót, vagy rám hallgat, telepakolunk egy diszk bladet, és az kurvára pont elég lesz vagy két évig. És lőn.

Na, de ez off :)

Viszont jellemzően nem is kerül diszkre 4k-nál kevesebb adat, mert ott van előtte a fájlrendszer cache, és az "összevárja". Ha bájtonként külön csomagban írod a fájlt, jó eséllyel csak a hasznos sávszélességet csökkented, a szükséges IOPS-t nem növeled. (Persze mindig lehet keresni extrém példákat, amikor ez nem igaz)

Virtualizált környezetben is azért ad ki 4k-t a guest OS, mert nem "nyersen" írják az NFS-t, hanem ott van előtte a guest OS fs-e, ami fölött az fs cache összegyűjti az írási művelteket 1 csokorba.

Ez roppant hasonló ahhoz, amikor nincs virtualizált környezet, hanem az NFS-ről lejövő adatot az NFS szerver fs cache-e összegyűjti, és 4/8k -s blokkos írássá alakítja. A vége ugyan annyi IOPS, szóval az eredmények használhetók itt is.

Általános fájlrendszeren a (kis) fájlok ritkán terülnek el szekvenciálisan a diszken mert abból oltári fragmentáció lehetne, azzal a legritkább esetben tud optimalizálni a blockdev, hogy több apró fájl írását egy IO alá vonja (a metaadatokról és a journalról nem is beszélve).

De pl a nagy fájl + 1 bájtos random módosítás (rewrite) is rendesen meg tudná izzasztani a blockdev-et az NFS mögött, miközben a network malmozik.

Minden a workload-tól függ..

Az ext4 pl. a 60 byte-nál kisebb fájlokat berakja az inode-ba, és ezek jó eséllyel egymás mellé kerülnek. A btrfs is egy metadata blockba pakol több kis fájlt.

De mindenki kipróbálhatja otthon, létrehoz mondjuk százezer darab pár bájtos fájlt egy shell scriptből, és kiadja a syncet. Ha neked van igazad, akkor a művelet százezer IOPS költségű közelítőleg, azaz egy hagyományos 5400 RPM-es diszken ~1200 másodpercig, azaz 20 percig tart. Ha ennél jóval gyorsabban végez, akkor jóval kevesebb iopsról beszélünk. A legegyszerűbb teszt:

dd if=/dev/zero of=masterfile bs=1000 count=100000
date; split -b 1000 -a 10 masterfile; sync; date

Ez 100.000 kis fájlt (1000 byte) hoz létre. Nálam ez hagyományos diszken (7200 RPM-es SAS) ext3 fájlrendszer alatt 21 másodpercig tart, nem 20 percig. Mivel gyors egymásutánban 200 megát mozgat meg a program, a HDD saját cache nem igazán számít.

Hű, tényleg igaz, hogy a fájlok/mappák létrehozása már szépen összevonódik, akkor is mappába hasítom szét őket (az ext3-nak ez gyenge pontja volt arra emlékszem).

De ha pl azt csinalod, hogy: 

[dap@dh b]$ echo x >x && ( seq -w 1 100000 | xargs -I{} cp x {}; sync )
[dap@dh b]$ awk '/sdb /{ print $8 }' /proc/diskstats
2139916
[dap@dh b]$ echo x >x && ( seq -w 1 100000 | xargs -I{} cp x {}; sync )
[dap@dh b]$ awk '/sdb /{ print $8 }' /proc/diskstats
2238059

Akkor 4KB-os blokkokat ír a diszk és 100.000 fájra kb 100.000 IO lesz az 1 bájtos rewrite. (Mondjuk ez is meglepően jó, a metaadat/journal írások jól összevonódnak. A rewrite hamar lefut, mert közeli blokkokba ír, nem cibálja a HDD fejet.)

Persze ezek szintetikus tesztek, az élet kegyetlenebb is lehet. :)

Ahogy egy korábbi szavazás felrémlett, az jutott eszembe, hogy azok a fejlesztők írnak olyan alkalmazásokat, amelyek 100,000 apró fájl írásakor darabonként sync-elnek, akiknek fogalmuk sincs az üzemeltetésről(*).

A félreértések elkerülése végett, azok is ilyenek akik 100,001 fájl esetén. I tak dalse.

*) vagy tesztprogramot fejleszt, vagy be akarja sározni a beszállítót, hogy milyen silány hardvert hozott, hogy 100M kiírásától már elpusztul. De legalább lesz értelme a BBWC-nek.

Igen, ilyesmiken merengtem a metrón, és ugye az a kérdés, hogy másodpercenként hány levél esik be. Ha a fenti, másodpercenkénti 100,000 levél, akkor azért az már egy más infrastruktúrát igényel, pl. nem egy szervert, amin nfs-en át ír. Legalábbis én nem aludnék nyugodtan.

Tehát igen, előállhat a 100,000 körüli sync/s esete, de ahol az fontos, hogy ezek az adatok biztonságban kikerüljenek a diskre, ott alighanem nem nfs és giabit mögött van storage.

Igen, lehet teremteni olyan környezetet amiben az nfs/gigabit megfekszik 100M adat kiírásától, de ha az a cél, akkor kb. bármilyen technológiáról be lehet bizonyítani, hogy életképtelen.

Az a nagy büdös helyzet, hogy valódi szerver környezetben az adataid egy sync-től a legritkább esetben kerülnek a diszkre. Elmennek a szerver FC kártyájától a valamilyen volume controllerig (ami vagy egybe van építve a storage-gal, vagy nincs) ami jó sok cache-t biztosít a diszkek elé. Innen elkerülnek a storage cache-be egy idő után. Innen elmennek a diszk saját cache-ébe, majd a végén innen íródnak a diszkre - ha egyáltalán, mert jó eséllyel valamelyik cache-ben felülírás miatt invalidálódnak már előbb.

Ezek az elemek ugyan olyan hardver elemekből felépített, ráadásul időnként Linuxot futtató cuccok, mint amilyen a szervered is. Az, hogy miben bízol jobban:
- a szerveredben a memóriát megvédi az ECC meg a szünetmentes, és nincs a linux kernelben olyan hiba, ami szofveres összeomlást okoz
- vagy hogy ezekben az eszközökben megvédi a memóriát az ECC meg a szünetmentes, és a firmware-ben sincs adatvesztést okozó hiba

nos, inkább csak hit kérdése.

Kicsit nehezen bírom követni, hogy jutottunk el az "nfs/gigabit esetben az elméleti maximum 30k IOPS körül van" kijelentéstől az NFS felett (?) diszk image-eket elérő virtuális környezeten át a "valódi" szerver környezethez, amely FC SAN-on ír ki olyan adatokat a cache-ekbe, amelyek jó eséllyel felülírás miatt úgyis invalidálódnak, még mielőtt a diszket elérnék. (ez a jellemző írási minta a valódi szerverkörnyezetben?)

Értem, enterprise környezetben dolgozol, és az alapján általánosítasz -ráadásul egy olyan topicban, ami nem ilyen környezetről szól. :)

Ne fázz tőle. Persze desktop ssd meg gagyisztáni vezérlő problémás lehet, de ha normális motyót raksz össze, akkor nyugodtan lehet tőle aludni. Saját tapasztalat - a site-ot nem nevezném meg, de hogy a maga nemében az egyik nagy, annyit le lehet róla írni - igaz, az ssd-n csücsülő mysql csak az egyik komponense a szolgáltatásnak. Ott mondjuk az ssd nem nfs-t, hanem közvetlenül a db-t szolgálta ki.

( hnsz2002 v | 2014. 08. 01., p – 11:17 )

Én akárhányszor próbáltam beüzemelni NFS szervert, mindig ilyenbe futottam bele, és nem tudtam rá megoldást találni. Soha nem működött rendesen.
Hiába mondták mások hogy tökéletesen megy, ugyanazok az opciókat használtam, nekem rw-ben sose volt jó az NFS. Ugyanez a rohadt magas load a szerveren, és néha a kliensen is (nem, nem a diszk a szűk, a diszk 800K-val ír iotop szerint, vagy semmit nem csinál), egyszerűen berohad a kapcsolat másolás közben, megáll, és olyan deadlockba kerül, hogy se kikillezni a processzt, de még újraindítani sem lehet a gépet, csak force módszerrel. Ha ez nem történik meg, és esetleg még sikerül is felmásolni egy fájl, akkor is gyötrelmes sebességgel, SMB fényévekkel gyorsabb, nem szakad meg, nincs deadlock...
Próbáltam több szerverrel több klienssel, nem ment sose. Inkább SMB-zek fájlmegosztásra linux-linux közt is. Stabil. Ezzel nem azt mondom hogy te is használd ezt, csak leírtam, hogy én már feladtam az NFS-t.
--
The Community ENTerprise Operating System

Semennyire. Ha anonymous share-ed van, akkor nobody:nobody a létrejövő fájlok tulaja, a megadott create és directory maskokkal. Ha authentikáció van, akkor meg azzal a userrel, akivel authentikáltál. A szerverről lemásolt, helyi gépen létrejövő fájlok pedig nyilván az adott user tulajjal, a fájlra vonatkozó default jogokkal kreálódik.
Kizárólag akkor fog egybevágni, ha domain van, és mindkettő a tagja valamilyen formában, és onnan veszik a usereket.
--
The Community ENTerprise Operating System

( gabrielakos v | 2014. 08. 01., p – 16:59 )

Amit leírtak, hogy a diszk a kevés és ssd kéne, azt én is megerősítem.
Továbbá azt is, hogy NFS-sel sose lesz igazán jó, v4-el se.
NFSv4-et én backupra használtam dirvish-sel, de kidobtam mert lassú és megbízhatatlan volt. Ugyanaz a vas duply-val simán kiszolgálja amit kell.
Ez számodra persze nem túl nagy segítség.

Glusterfs, iscsi hogy két opciót mondjak amerre el lehet indulni.

Sajna egyelőre nincs hosszú távú tapasztalatom egyikkel sem, majd talán egy év múlva.

--
Gábriel Ákos
http://i-logic.hu

Ezzel persze egyet is lehet érteni, de nyilván az SSD alapú storage egyelőre sokkal drágább, mondjuk egy 4TB-os storage-et megfelelő redundanciával összehozni nem kis pénz.
Én most a flashcache-ben "hiszek", most a pre-production teszt fázisban van, eddig jó, sőt atom jó.

--
Gábriel Ákos
http://i-logic.hu

( zolo | 2014. 08. 02., szo – 10:57 )

Latom, ez ilyen olcso projekt, igy tegyel az NFS serverbe 4 discet, SW Raid 10.
Illetve, azt gondolom, eleg neked az NFSv2 is.

( dikki | 2014. 08. 03., v – 09:31 )

jelentősen nagyobb sebességet nem fogsz elérni, valószínűleg - ahogy mások is mondták - a szerver 1 szem hdd-je a szűk keresztmetszet.

igazából csinálhatnál egy tmpfs exportot a szerveren, és megnézhetnéd, arra mennyivel tudsz írni.
ha nagyon gyorsan, akkor a hálózat és az egyéb beállításokkal talán nincs gond.

nfs téren amit én lejjebb vennék, az a blocksize, 1m szerintem sok.
a /proc/sys/sunrpc/tcp_slot_table_entries számát kicsit feljebb veheted. 128 pl.

ami talán még nem hangzott el: a szerveren megnézném, hogy nem misaligned-e a fájlrendszer.

ez a tmpfs ötlet nem is rossz. köszi, ezt valamikor meg fogom nézni -- csak az a cinkes, hogy közben nem szállhat el a gép, mert akkor akkora inkonzisztencia lépne fel, hogy ihaj.

a block size-ot visszavettem 4k-ra, még azon volt a legjobb, mielőtt átmenetileg (vakációra jöttem) felhagytam volna az nfs-es résszel. reménytelen volt, kvázi akármit akárhogy konfiguráltam, egy rövid felfutási idő alatt beálltak a földbe az appserverek (120-as loadok pl, de az nfs iowait miatt, mert közben simán lehetett bármit csinálni a konzolon).

arra vigyáztam, hogy ne legyen misaligned a FS, tehát az tutira nem.

Mikor érdemes adatbázis alá NFS-t tolni?
NFS-t valamikor nagyon régen akartam használni, a szerver ráadásul VMS lett volna, de olyan lassú volt, hogy villámgyorsan kitaláltunk valami mást.
OK, egy modern, linuxos/unixos NFS szerver sokkal gyorsabb, de nekem még így is furcsa, hogy adatbázis alá...

Mert?
Arra nem nagyon lehet szükség, hogy adatbázis fájlokat, az adatbázis szerver megkerülésével érj el több helyről.
Kényszerhelyzetben előfordulhat, hogy nem tudod máshol elhelyezni a fájlokat, de ha van rá mód, hogy ne nfs-t használj...
Rég volt, nem akarom a hiányos emlékeim alapján részletezni, mennyi plusz problémát hordoz egy ilyen megoldás, de szerintem rengeteget.

Az nfs nem gyors, ellenben lassú a lokális akármilyen diszkhez képest. De ez csak Perfor Mancikát érdekli, a nagyobb gond ott van, hogy "némileg" több rétegen/eszközön suhan (cö-cö... tötymörög) át az adat, és a konzisztenciát bármelyik réteg hibája/kiesése agyon tudja ütni.

Adatbázisfájlok elérése több helyről... Fájl szinten nem igazán van értelme, épp, a konzisztencia megtartásának az érdekében - nem, a "user üti F5" nem fog konzisztens állapotot eredményezni :-) Az meg, hogy helyben _és_ nfs-en kiajánlva másik gépen is ráindítson valaki adott DB-fájlokra egy tetszőleges kiszolgálót, nos... Az tényleg öntökönböki. Persze vannak direkt fájlként matatható adatbázisok is, azoknál "csak" a teljesítmény lesz problémás első körben.

Nem mértem (még), de van egy bélásom arra, hogy ugyanazt a blokkos eszközt, ugyanazon a fizikai infrastruktúrán iSCSI-ként odaadva a kliensnek a lokális fs - nfs kör megfutása nélkül jóval kellemesebben terhelhető megoldást kapunk.

> nem mertem (meg)
szerencsere masok mar megtettek. alapveto különbseg az en olvasatomban nincs, vagy ha van, akkor csak a mienktöl elterö környezetben. pl. 1

az altalam regebben olvasott reportok alapjan ugy lattam, es ezert most is azt gondolom, hogy altalanossagban nem, vagy nem jelentösen gyorsabb az iscsi, ellenben magasabb cpu utillal jar. most ujabbat nem talaltam, de pl. 2 - azota az nfs is csak gyorsul, pl. VAAI megjelenese, pNFS stb.

es ezek a tesztek az OS nfs-client implementaciojat hasznaljak, pedig annal akad jobb is. 3

nyilvan mindenki maga dönti el, hogy mi kell neki, es nincs ket azonos rendszer. nekünk ez jo. te is tudnal 15 white papert citalni, hogy lassabb az nfs, en is 15-öt, hogy minimum olyan gyors mint barmi mas, föleg oracle-höz.

A látszat ellenére nem vagyok full hülye a témához(adatbázisok), max kimaradt pár év és két nfs verzió (2-est próbáltam használni - persze nem adatbázis alá)
;)
iscsi performancia előnyére nekem is lenne pár doboz söröm látatlanba. :)
Mondjuk ha samba vs nfs a téma, ott talán jöhet az nfs.

Adatbázis téma: kisebbeknél nem tudom, mi a helyzet, Oracle, Rdb, talán DB2 és még inkább talán MSSQL is tud olyat, hogy párhuzamosan, több gépről ugyanazokat a fájlokat használni, de itt shared storage van mögötte és nem nfs.
(Nem neked, csak az utókor számára - rólad feltételezem, hogy tisztában vagy ezekkel)

Nem ártana rendezni a soraid. :) A posztban még azt írod, hogy async exportot se akarsz annyira fontos az adatbiztonság, most meg már a tmpfs is szóba jöhet?

Ha async export lenne, óriási előnyre tennél szert a mostani teljesítményhez képest.

A BBWC RAID kontroller azért jó, mert NFS sync export mellett sem kell elmenni a diszkig az adatnak, elég ha az NVRAM-ig elmegy, onnan meg már kevesebbet, illetve kevésbé fragmentált adatot kell kiírni a tányérra. Az SSD-nek szerintem ez a sok random write nem ideális terhelés, de pusztán nyers erőből is meg fogja oldani. Mindenesetre az is hálás lenne (élettartam, burst latency) ha az async exportot megfontolnád.

Ha pedig lehet tmpfs, akkor legyen tmpfs. Szerintem ebből érdemes választani, a többi csak szarlapátolás. :)

Már a konzumer SSD-nél is ritkán gond, mert a HDD-hez képest még így is fényévekkel gyorsabbak és ez még mindig szempont.

Futottam egy kört a guglival és 10 perc után úgy látom, hogy az enterprise SSD ott jár, hogy nagyobb over-provisioning -gel tünteti kezelést alkalmaz erre a nyavajára. Meg nem oldották, mert néhány grafikon alapján 100+%-os extrém OP mellett is elillan a teljesítmény 35-40% -a, 20-30% körüli OP-vel (kb ez az enterprise kategória) a teljesítmény 70%-a ugrik. Mondjuk ez a worst-case, amikor teljesen csurdultig tolják az SSD-t adattal és full random IO-val kínozzák.

Erre értettem, hogy a probléma adott, de a nyers erő megoldja. De ez tényleg csak 10 perc gugli eredménye.

Ezt a "nem idealis" reszt nem ertem en. Van olyan, aminek az az idealis? Vagy nem ertem, mire irtad.
Ez egy olyan adott parameter, amin viszonylag a legkevesbe lehet szerintem valtoztatni.

Ilyen ertelemben nincs ertelme kijelenteni, h idealis vagy nem.

Amugy hajlok arra, hogy az emberunk nem is akarja megoldani a problemat, mivel 1 het alatt semmi elorelepes nem volt a thread-ben (vagy csak atfutottam?).
Esetleg a problema nem is akkor, mint amekkoranak beallitotta:)

cöcö. tessék olvasni. :) a tmpfs-es dolog csak TESZTNEK lenne jó, hogy meglássuk, az NFS maga mennyit fog vissza a teljesítményből. mert ha ott az jön ki, hogy úgy NFS-el simán pörög az egész, akkor egyértelmű, hogy valami brutál gyors RAID10-es megoldást kell alá tolni. ha az jön ki viszont, hogy úgy is beszakadnak az appszerverek, akkor az NFSt kell valami működő dologra cserélni.

( igor | 2014. 08. 04., h – 09:47 )

A disk cserén felül én minimalizálnám a disken IO mértékét is. Tegyél még az nginx elé egy varnish-t is!

mit érnék vele? a statikus tartalmakat eddig is sendfile() szolgálta ki (ami azért tudomásom szerint becache-eli, kernel szinten, a fájlt, amit éppen átküldene, és tartja is egy jó darabig -- kvázi a disk io-t megkerüli az első beolvasás után), a php-s oldalak viszont full dinamikusak, tehát ott a varnish semmit nem érne.

A php oldalak másodpercenként új tartalmat adnak? Mert ha nem, akkor máris van értelme a varnishnak. Nyilván szolgáltatás függő, de általában a gyors, 1-5 perc cache elévülés még a nagy forgalmú site-oknak is elegendő szokott lenni. Ahol meg fontos, hogy bizonyos tartalmak azonnal jelenjenek meg, ott a varnish configjával ezt követni tudod.

( zoner | 2014. 08. 05., k – 12:47 )

cachefilesd a baratod. A klienseken ott lesz egy teljes masolat az NFS megosztasrol, tehat nem eszi meg a szervert az iowait

( zoner | 2014. 08. 06., sze – 14:25 )

Esetleg kikapcsolni a journaling-ot ext4-ben?

A raspberry-n az USB HDD sleep miatt kapcsoltam ki, mert nem akart lekapcsolni, ha nem hasznalta a disket. De utana jelentosen csokkent az iowait is.