Discussion:
nfsroot gyorsitasa helyi diszkekkel
Horváth Ágoston János
2004-08-31 11:12:38 UTC
Permalink
Udv!

A kisse lassucska diskless nfsroot rendszeremet akarom felgyorsitani.
Tobb gond is volt vele:
- a lassu IO miatt minden 2/3-1/2 sebesseggel futott
- swap hianya miatt baromi sok memoria mellett is dobalta a OOM kill-eket.

Arra gondoltam, hogy otvozom a lokalis gepekben levo vinyo sebesseget
az nfs konnyu adminisztraciojaval a kovetkezokeppen:
- lokalis /home iras/olvasas a helyi gep vinyojara tortenik, majd a
hatterben folyamatosan replikalodik at a szerverre illetve a tobbi
kliensre
- a szerveren a /home read-only
- a szerveren a konfig modositasa (/usr, /etc, ...) atreplikalodik az
osszes kliensgep vinyojara

Ennel a megoldasnal gond lenne ugyan valamelyest, hogy nagyobb a
latency, egyik kliens irasi muveletet a masik lassabban veszi eszre,
viszont a helyi geprol torteno olvasas akkora teljesitmeny-novekedest
jelentene, hogy boven megerne.

A kerdes, hogy milyen kesz megoldasok vannak erre, melyik a legjobb, stb...?
KORN Andras
2004-08-31 11:25:04 UTC
Permalink
Post by Horváth Ágoston János
A kisse lassucska diskless nfsroot rendszeremet akarom felgyorsitani.
- a lassu IO miatt minden 2/3-1/2 sebesseggel futott
- swap hianya miatt baromi sok memoria mellett is dobalta a OOM kill-eket.
Arra gondoltam, hogy otvozom a lokalis gepekben levo vinyo sebesseget
- lokalis /home iras/olvasas a helyi gep vinyojara tortenik, majd a
hatterben folyamatosan replikalodik at a szerverre illetve a tobbi
kliensre
- a szerveren a /home read-only
- a szerveren a konfig modositasa (/usr, /etc, ...) atreplikalodik az
osszes kliensgep vinyojara
Ennel a megoldasnal gond lenne ugyan valamelyest, hogy nagyobb a
latency, egyik kliens irasi muveletet a masik lassabban veszi eszre,
viszont a helyi geprol torteno olvasas akkora teljesitmeny-novekedest
jelentene, hogy boven megerne.
A kerdes, hogy milyen kesz megoldasok vannak erre, melyik a legjobb, stb...?
Un. eloszott filerendszer kell neked. Ilyen pl. a coda, az intermezzo, az
andrewfs... Meg van egy gfs nevu is, ha jol remlik.

De lehet hogy egyszerubb lenne, ha a /home kivetelevel minden a kliensen
lenne, es idonkent frissitened az nfsroot master-peldanyrol, a /home pedig
maradna a szerveren. Vagy a /home-hoz valo hozzaferesek lassusaga a gond,
nem pl. a programok elindulasa?

Guy
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
2B or not 2B, that is FF.
Horváth Ágoston János
2004-08-31 11:31:50 UTC
Permalink
On Tue, 31 Aug 2004 13:25:04 +0200, KORN Andras
Post by KORN Andras
Un. eloszott filerendszer kell neked. Ilyen pl. a coda, az intermezzo, az
andrewfs... Meg van egy gfs nevu is, ha jol remlik.
Igen, ezekrol en is hallottam/olvastam, de konkret tapasztalatok erdekelnenek.
Post by KORN Andras
De lehet hogy egyszerubb lenne, ha a /home kivetelevel minden a kliensen
lenne, es idonkent frissitened az nfsroot master-peldanyrol, a /home pedig
maradna a szerveren. Vagy a /home-hoz valo hozzaferesek lassusaga a gond,
nem pl. a programok elindulasa?
A /home -hoz valo hozzaferes lassusaga a gond.
A rendszer frissitese valoban megoldhato kesobb is, de abbol is jobb
lenne az azonnali (gyors javitasok eseten pl., hogy ne kelljen gyorsan
megcsinalni kezzel az osszes gepen).
Andras Horvath
2004-08-31 11:59:45 UTC
Permalink
Post by Horváth Ágoston János
Igen, ezekrol en is hallottam/olvastam, de konkret tapasztalatok erdekelnenek.
AFS kvazi problemamentesen megy jo sok gepen, bar kisse bonyolult
(kerberos kell hozza), es root FS-t nem fogsz tudni ratenni. Van benne
lokalis disk cache.
Post by Horváth Ágoston János
A /home -hoz valo hozzaferes lassusaga a gond.
Meg kellene nezni, hogy mi van tele a kliensen (cpu? memoria? halozati
interface?), amikor teljes sebesseggel (lassusaggal) ir a home-ba. Abbol
okosabbak lennenk. Gyanum szerint halozat vagy CPU problemad lesz.
Esetleg nem a szerver tul lassu veletlenul? (ugyanezeket a
statisztikakat erdemes lenne ott is megnezni.)

Ha az iras nagyon lassu, akkor az AFS lehet, hogy segit valamit, de
egyik halozatos filerendszer sem a sebessegerol hires. Ha csak ugy
altalaban lassu az NFS minden "ertelmes magyarazat" (hw korlat) nelkul,
akkor a megfelelo mount opciokkal (rsize=, wsize=) gyorsabba teheto.

A swap hianyat pedig gyorsan es egyszeruen orvosolhatod egy lokalis swap
particioval :)
Post by Horváth Ágoston János
A rendszer frissitese valoban megoldhato kesobb is, de abbol is jobb
lenne az azonnali (gyors javitasok eseten pl., hogy ne kelljen gyorsan
megcsinalni kezzel az osszes gepen).
Ha pl. minden bootnal egy altalad elokeszitett repositorybol update-eled
a csomagokat, nem kell semmit kezzel megcsinalnod.

udv, HTH
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Horváth Ágoston János
2004-08-31 12:20:16 UTC
Permalink
On Tue, 31 Aug 2004 11:59:45 +0000 (UTC), Andras Horvath
Post by Andras Horvath
AFS kvazi problemamentesen megy jo sok gepen, bar kisse bonyolult
(kerberos kell hozza), es root FS-t nem fogsz tudni ratenni. Van benne
lokalis disk cache.
Lokal vinyorol kellene bootlniuk a gepeknek, ugyhogy nem gond a root fs hianya.
Post by Andras Horvath
Post by Horváth Ágoston János
A /home -hoz valo hozzaferes lassusaga a gond.
Meg kellene nezni, hogy mi van tele a kliensen (cpu? memoria? halozati
interface?), amikor teljes sebesseggel (lassusaggal) ir a home-ba. Abbol
okosabbak lennenk. Gyanum szerint halozat vagy CPU problemad lesz.
Esetleg nem a szerver tul lassu veletlenul? (ugyanezeket a
statisztikakat erdemes lenne ott is megnezni.)
Nem az a gond, hogy elfogy valamilyen eroforras, hanem az, hogy az
osszes kliens a szervergep vinyojat terheli, raadasul nfs-nel a seek
time-ra ugye rajon meg a halozat latency-je is. Szo szerint az nfs
nagy kesleltetese fogja vissza a teljesitmenyt. CPU, halozat
savszelesseg maradt boven.
Post by Andras Horvath
Ha az iras nagyon lassu, akkor az AFS lehet, hogy segit valamit, de
egyik halozatos filerendszer sem a sebessegerol hires. Ha csak ugy
altalaban lassu az NFS minden "ertelmes magyarazat" (hw korlat) nelkul,
akkor a megfelelo mount opciokkal (rsize=, wsize=) gyorsabba teheto.
Nem kell gyorsnak lennie. Csak az a cel, hogy par masodpercen belul
megjelenjen az osszes kliensgep vinyojan. Tehat kb. mint az nfsroot,
csak tenylegesen latni akarom a lokalgep vinyojan.
Amolyan lassu, de folyamatos szinkronra lenne szukseg.
Post by Andras Horvath
A swap hianyat pedig gyorsan es egyszeruen orvosolhatod egy lokalis swap
particioval :)
Na ja, de csak emiatt betenni egy vinyot a gepekbe enyhe tulzas.
Post by Andras Horvath
Post by Horváth Ágoston János
A rendszer frissitese valoban megoldhato kesobb is, de abbol is jobb
lenne az azonnali (gyors javitasok eseten pl., hogy ne kelljen gyorsan
megcsinalni kezzel az osszes gepen).
Ha pl. minden bootnal egy altalad elokeszitett repositorybol update-eled
a csomagokat, nem kell semmit kezzel megcsinalnod.
Minden bootnal, na ja, es az en szep ket szememert ujrabootolnak a
gepuket, ujrainditgatnak a programjaikat, ujra belepnenek mindenhova?
Ez nem mukodne.
Andras Horvath
2004-08-31 12:56:18 UTC
Permalink
Post by Horváth Ágoston János
Nem az a gond, hogy elfogy valamilyen eroforras, hanem az, hogy az
osszes kliens a szervergep vinyojat terheli, raadasul nfs-nel a seek
time-ra ugye rajon meg a halozat latency-je is. Szo szerint az nfs
nagy kesleltetese fogja vissza a teljesitmenyt. CPU, halozat
savszelesseg maradt boven.
ez van, kisebb latency-ju halozatot kell venni :-) infiniband,
quadrics4, ilyenek :-)

persze ha kicsit is nagyobb file-jaid vannak (tizmegas office doksik,
fotok, mittommik), akkor megiscsak jatszanek azzal az NFS
blokkmerettel.

A szerveren levo vinyo mint szuk keresztmetszet valoban all, vagy csak
mernoki tipp? Elobbi esetben oda lehetne egy gyorsabb diszkalrendszert
produkalni.
Post by Horváth Ágoston János
Nem kell gyorsnak lennie. Csak az a cel, hogy par masodpercen belul
megjelenjen az osszes kliensgep vinyojan. Tehat kb. mint az nfsroot,
csak tenylegesen latni akarom a lokalgep vinyojan.
Amolyan lassu, de folyamatos szinkronra lenne szukseg.
ez miert szukseges?
Post by Horváth Ágoston János
Na ja, de csak emiatt betenni egy vinyot a gepekbe enyhe tulzas.
bocsanat, azt hittem, hogy mar most is van disk minden gepben.
Post by Horváth Ágoston János
Minden bootnal, na ja, es az en szep ket szememert ujrabootolnak a
gepuket, ujrainditgatnak a programjaikat, ujra belepnenek mindenhova?
Lehet cronbol is :) Ha sok geped van, akkor gepenkent profile-ok
szernit; ha nem akarsz varialni, akkor amit leteszel a repositoryba, azt
orankent felnyalja valamilyen script a klienseken, es ha van ujdonsag,
akkor frissit. (Bar nem latom, hogy desktop gepeken mire a sietosseg -
ha security update-ed van, akkor egy script korbessh-zik es feltolja
mindenkinek az uj akarmicsoda verziot.)

hm?

raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Horváth Ágoston János
2004-08-31 13:37:16 UTC
Permalink
Post by Andras Horvath
ez van, kisebb latency-ju halozatot kell venni :-) infiniband,
quadrics4, ilyenek :-)
:) Hja, en is szeretnek ilyen helyen dolgozni :)
Post by Andras Horvath
persze ha kicsit is nagyobb file-jaid vannak (tizmegas office doksik,
fotok, mittommik), akkor megiscsak jatszanek azzal az NFS
blokkmerettel.
Nem irtam ugyan, de azt meg akkor beallitottam, amikor az nfs-t
osszelottem. Minden masodik nfsroot-forras leirja.
Post by Andras Horvath
A szerveren levo vinyo mint szuk keresztmetszet valoban all, vagy csak
mernoki tipp? Elobbi esetben oda lehetne egy gyorsabb diszkalrendszert
produkalni.
Mar most is raid1 van.
A szuk keresztmetszet valoban mernoki becsles, amit a vinyoledre, az
azzal aranyban allo valaszidokre, a gkrellm diszk-monitorara es a
mernoki hasra alapoztam.
Nekem korrektnek tunik. :))

Viccet felreteve, az IS szuk keresztmetszet, amit egy lokalvinyos
rendszer megoldana (meg meg sok mast is).
Post by Andras Horvath
Post by Horváth Ágoston János
Nem kell gyorsnak lennie. Csak az a cel, hogy par masodpercen belul
megjelenjen az osszes kliensgep vinyojan. Tehat kb. mint az nfsroot,
csak tenylegesen latni akarom a lokalgep vinyojan.
Amolyan lassu, de folyamatos szinkronra lenne szukseg.
ez miert szukseges?
Mert, mint irtam, nekem egy teljesen ugyanolyan rendszer kellene, mint
az nfsroot, csak epp azt szeretnem, ha a user szemszogebol az osszes
diszk iras-olvasas lokalis vinyora tortenjen, annak megfelelo
sebesseggel persze. Aztan hogy 0.001 vagy 5 masodperccel kesobb kezd
el latszani a user modositasa egy masik gepen, arra nagy ivben teszek,
majd megoldjak egymas kozt.
Post by Andras Horvath
Post by Horváth Ágoston János
Na ja, de csak emiatt betenni egy vinyot a gepekbe enyhe tulzas.
bocsanat, azt hittem, hogy mar most is van disk minden gepben.
Nem, dacara a mernoki hasnak, azert tervezni is szoktam neha. Nincs
kidobnivalo penz. Meg konnyebben lenyelik odafent, ha egy alaposan
atgondolt tervet latnak, es nem egy "haaaaat, biztos jobb" tipusu
valaszt.
Post by Andras Horvath
Post by Horváth Ágoston János
Minden bootnal, na ja, es az en szep ket szememert ujrabootolnak a
gepuket, ujrainditgatnak a programjaikat, ujra belepnenek mindenhova?
Lehet cronbol is :)
Az azert nem jo, mert nem fogom elore tudni, hogy mikor figyeljek
nagyon a hatam moge :)))
Post by Andras Horvath
Ha sok geped van, akkor gepenkent profile-ok
szernit; ha nem akarsz varialni, akkor amit leteszel a repositoryba, azt
orankent felnyalja valamilyen script a klienseken, es ha van ujdonsag,
akkor frissit. (Bar nem latom, hogy desktop gepeken mire a sietosseg -
ha security update-ed van, akkor egy script korbessh-zik es feltolja
mindenkinek az uj akarmicsoda verziot.)
Persze, nyilvan igy lehetne megoldani a feladat egyik felet (a /home
replikalasa akkor is problemas), de pont azert kerdeztem ra, hatha van
mar keszen egy elosztott filerendszer, ami ezt nekem pikk-pakk
kenyelmesen megoldja.
A sietosseg oka sokfele lehet. Altalaban valoban nem kritikus, hogy
rogton lassak, de legalabbis igen jol jonne, es igen kenyelmes (pl. en
nem szoktam ok nelkul frissitgetni; marpedig ha oka van, akkor szukseg
lenne a frissebb verziora, de azonnal).
Andras Horvath
2004-08-31 14:09:17 UTC
Permalink
Post by Horváth Ágoston János
Mar most is raid1 van.
raid1 = mirror, az nem eppen teljesitmenycelokat szolgal.
Post by Horváth Ágoston János
Mert, mint irtam, nekem egy teljesen ugyanolyan rendszer kellene, mint
az nfsroot, csak epp azt szeretnem, ha a user szemszogebol az osszes
diszk iras-olvasas lokalis vinyora tortenjen, annak megfelelo
sebesseggel persze. Aztan hogy 0.001 vagy 5 masodperccel kesobb kezd
ezt a rendszerfrissitesre irtad...
Post by Horváth Ágoston János
Persze, nyilvan igy lehetne megoldani a feladat egyik felet (a /home
replikalasa akkor is problemas), de pont azert kerdeztem ra, hatha van
mar keszen egy elosztott filerendszer, ami ezt nekem pikk-pakk
kenyelmesen megoldja.
A sietosseg oka sokfele lehet. Altalaban valoban nem kritikus, hogy
rogton lassak, de legalabbis igen jol jonne, es igen kenyelmes (pl. en
nem szoktam ok nelkul frissitgetni; marpedig ha oka van, akkor szukseg
lenne a frissebb verziora, de azonnal).
eddig is azt emlegettuk, hogy a rendszer legyen lokalis diszken
(idoszakos frissitessel), a home-okra meg nekunk kivaloan bejott az AFS.

(Tenyleg, NFSv4-et probalt mar ki valaki ugy komolyabban?)

szerintem tobbet nem tudunk elmeletben hozzatenni, kaptal jonehany
tippet.

udv
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Mezei Zoltan
2004-08-31 14:20:38 UTC
Permalink
Szia!
Post by Andras Horvath
Post by Horváth Ágoston János
Mar most is raid1 van.
raid1 = mirror, az nem eppen teljesitmenycelokat szolgal.
De alapvetoen barmilyen intelligensebb kontoller megcsinalja az
olvasasra optimalizalast: ha mindket diszk elerheto, akkor fele-fele
aranyban olvas innen-onnan. Irasra a RAID0 a legyorsabb.
--
Zizi

"Meg nincs teljesen kesz, de mar majdnem elkezdtuk!"
Andras Horvath
2004-09-01 08:16:54 UTC
Permalink
Post by Mezei Zoltan
De alapvetoen barmilyen intelligensebb kontoller megcsinalja az
olvasasra optimalizalast: ha mindket diszk elerheto, akkor fele-fele
aranyban olvas innen-onnan. Irasra a RAID0 a legyorsabb.
az elobbi igaz, nem fogalmaztam pontosan (bar a mirrort inkabb azert
szeretjuk, mert nem kell sokat szamolgatni iraskor), az utobbi csak
streaming I/O-ra altalaban. YMMV.

udv
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Horváth Ágoston János
2004-08-31 15:42:14 UTC
Permalink
Post by Andras Horvath
Post by Horváth Ágoston János
Mar most is raid1 van.
raid1 = mirror, az nem eppen teljesitmenycelokat szolgal.
tom, csak a teljesitmenynoveleshez ketszer annyi diszk kene, ahhoz meg
mar komplett szervergepet is cserelni kellene, azt meg inkabb megse.
Post by Andras Horvath
Post by Horváth Ágoston János
Mert, mint irtam, nekem egy teljesen ugyanolyan rendszer kellene, mint
az nfsroot, csak epp azt szeretnem, ha a user szemszogebol az osszes
diszk iras-olvasas lokalis vinyora tortenjen, annak megfelelo
sebesseggel persze. Aztan hogy 0.001 vagy 5 masodperccel kesobb kezd
ezt a rendszerfrissitesre irtad...
Arra is. A ketto elegge ugyanaz. Ha a home-os elosztott filerendszer
megvan, akkor mar a masik is menne.
Post by Andras Horvath
eddig is azt emlegettuk, hogy a rendszer legyen lokalis diszken
(idoszakos frissitessel), a home-okra meg nekunk kivaloan bejott az AFS.
Nnna, vegre a lenyeg.
En is korbeneztem kozben: coda, intermezzo beta allapotu, gfs-t
frissen adta ki a redhat, es egyebkent is SAN-okhoz jo, mert osztott
diszket feltetelez; marad az afs, ami meg veszett bonyinak tunik nekem
elsore, meg az nfsv4, ami meg szinten experimental, bar van benne
migration es replication, ketsegeim vannak afelol, hogy ezeket
implementaltak is.

Osszefoglalva, egy olyan halozati filerendszerre lenne szuksegem, ami
az osszes adatot az osszes diszken eltarolja, es ha valamelyik peldany
modosult, annak valtozasait replikalja a tobbire. Kvazi nem is uj
filerendszerrol van szo, hanem egy olyan rendszerrol, ami sok-sok
modosithato peldanyt szinkronban tart.
Andras Horvath
2004-09-01 08:29:04 UTC
Permalink
Post by Horváth Ágoston János
Osszefoglalva, egy olyan halozati filerendszerre lenne szuksegem, ami
az osszes adatot az osszes diszken eltarolja, es ha valamelyik peldany
modosult, annak valtozasait replikalja a tobbire. Kvazi nem is uj
filerendszerrol van szo, hanem egy olyan rendszerrol, ami sok-sok
modosithato peldanyt szinkronban tart.
a szinkronban tartas egy nem trivialis problema. Ugye legalabb kozos
namespace kell hozza, meg mondjuk valamifele mechanizmus az utkozesek
feloldasara (pl. mandatory locking). Az elobbi meg egyszeru lehet, az
utobbi nem annyira.

En NEM javaslom, hogy a klienseken legyen valamifele "szinkronban
tartott" konyvtarstruktura, mert nem trivialis megoldani, es a
barkacsmegoldasok elobb-utobb ossze fognak dolni. Tenyleg annyira lassu
az NFS gigabit etherneten mondjuk? At kellene nezni - modszeresen -,
hogy hol a szuk keresztmetszeted.

Ha tenyleg elosztott adattarolasra van igenyed, akkor lustre (megpedig a
fizetos verzio!), esetleg meg lehet nezni, h a terrascale neven futo
elosztott filesystem tortenet most eppen hol tart (ez is penzes dolog),
bar egyik sem egeszen az, amit te szeretnel (ti. h mindenkinek mindenbol
van egy peldanya, aztan egymas kozt szinkronizalgatnak). Sot, dragabb
otleteim is vannak ;-)

udv, HTH, reszemrol nem tudok tobbet hozzatenni
raas

ps. az AFS (es a kerberos) bonyolult, igen.
pps. intermezzot meg codat nem szeretnel, az elobbi egy prototipus, az
utobbi meg nem mukodik normalisan.
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Horváth Ágoston János
2004-09-01 13:54:36 UTC
Permalink
Post by Andras Horvath
a szinkronban tartas egy nem trivialis problema. Ugye legalabb kozos
namespace kell hozza, meg mondjuk valamifele mechanizmus az utkozesek
feloldasara (pl. mandatory locking). Az elobbi meg egyszeru lehet, az
utobbi nem annyira.
Valoban nem trivialis, viszont igen potens megoldas lenne egy ilyen
rendszer. Gondoltam, hatha csinalt mar valaki, de ugy tunik, nem. Kar.
Post by Andras Horvath
a
barkacsmegoldasok elobb-utobb ossze fognak dolni. Tenyleg annyira lassu
az NFS gigabit etherneten mondjuk? At kellene nezni - modszeresen -,
hogy hol a szuk keresztmetszeted.
Na ez erdekes. Kicsit bovebben is kifejtem.
Frissen bootolt gepen Inditok mondjuk egy openoffice-t. Figyelem az
eroforrasokat: cpu kb. felig van hasznalva, halozati forgalom par szaz
K es par mega kozott ugral (100-as, terheletlen halo), nfs szerver
cpu-ja terheletlen, nfs szerver diszkje terheletlen.
En ebbol azt vontam le, hogy a halozat+nfs kesleltetese okozza a
lassusagot - vagyis se gigabites halo, se gyorsabb vinyo nem, vagy
csak alig-alig segitene. SCSI alapu halozatot meg azert megse epitek
ide.
Es mielott megkerdezned: NFSv3, rsize=32K, wsize=32K.
Post by Andras Horvath
Ha tenyleg elosztott adattarolasra van igenyed, akkor lustre (megpedig a
fizetos verzio!), esetleg meg lehet nezni, h a terrascale neven futo
elosztott filesystem tortenet most eppen hol tart (ez is penzes dolog),
bar egyik sem egeszen az, amit te szeretnel (ti. h mindenkinek mindenbol
van egy peldanya, aztan egymas kozt szinkronizalgatnak). Sot, dragabb
otleteim is vannak ;-)
Az se rossz, ha nincs meg az osszes helyen az adat, csak akkor
csinalja ugy, hogy hibaturo legyen (IDE diszkek, ugye...). Ezeket
megnezem.
Andras Horvath
2004-09-01 14:37:26 UTC
Permalink
Post by Horváth Ágoston János
En ebbol azt vontam le, hogy a halozat+nfs kesleltetese okozza a
lassusagot - vagyis se gigabites halo, se gyorsabb vinyo nem, vagy
[csak nem birom ki]

szerinted a latency hogyan valtozik, ha a FE halozatodat GE-re
csereled?..

raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Sickboy
2004-09-01 15:30:33 UTC
Permalink
Post by Andras Horvath
Post by Horváth Ágoston János
En ebbol azt vontam le, hogy a halozat+nfs kesleltetese okozza a
lassusagot - vagyis se gigabites halo, se gyorsabb vinyo nem, vagy
szerinted a latency hogyan valtozik, ha a FE halozatodat GE-re
csereled?..
Tippelek: tizedere csokken? :)


.SiCk of IT.
Mezei Zoltan
2004-09-01 15:55:29 UTC
Permalink
Szia!
Post by Sickboy
Post by Andras Horvath
szerinted a latency hogyan valtozik, ha a FE halozatodat GE-re
csereled?..
Tippelek: tizedere csokken? :)
A tipp helytelen. Nem, vagy csak minimalisan valtozik. Az atviteli
sebesseg es a latency kulonbozo fogalmak, eleg keves osszefuggessel a mega
vagy gigabites sebessegek kategoriajaban.
--
Zizi

"Meg nincs teljesen kesz, de mar majdnem elkezdtuk!"
Horváth Ágoston János
2004-09-01 15:51:37 UTC
Permalink
Post by Andras Horvath
[csak nem birom ki]
szerinted a latency hogyan valtozik, ha a FE halozatodat GE-re
csereled?..
Nem valtozik, mert az ethernet frame minimalis merete meg
nyolcszorosara no, hogy ne 10m legyen a max. madzaghossz.
Anno tesztelgettem is, a pontos eredmenyre mar nem emlekszem, de nem
estem hanyatt tole. 2 patch kabelen osszekotott intel 1000/mt -nek
max. a fele volt a latencyje, mint egy realtek kartyak+switch
variacionak.
Andras Horvath
2004-09-02 08:22:25 UTC
Permalink
Post by Horváth Ágoston János
Nem valtozik, mert az ethernet frame minimalis merete meg
nyolcszorosara no, hogy ne 10m legyen a max. madzaghossz.
ize, es minimummeretu frame-ek jonnekmennek, amikor openofficet
inditasz?

raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Sickboy
2004-09-01 15:55:42 UTC
Permalink
Post by Horváth Ágoston János
Mert, mint irtam, nekem egy teljesen ugyanolyan rendszer kellene, mint
az nfsroot, csak epp azt szeretnem, ha a user szemszogebol az osszes
diszk iras-olvasas lokalis vinyora tortenjen, annak megfelelo
sebesseggel persze. Aztan hogy 0.001 vagy 5 masodperccel kesobb kezd
el latszani a user modositasa egy masik gepen, arra nagy ivben teszek,
majd megoldjak egymas kozt.
"Megoldjak egymas kozt" ?
Marmint kik/mik?

Konkret problema, ami eszembe jut ezzel az elvarassal kapcsolatban:

Legyen xyz.doc (tegnapi modositasi datummal) ebben a szinkronizalt
strukturaban.
Mondjuk A gepen 10:00:00-kor elmentik valami modositassal.
(Legyen 5 masorperc az atszinkronizalodas, a pelda kedveert.)
Kozben azonban B gepen 10:00:03-kor megnyitjak, modositasra.
10:00:05-kor a B gepre ater az A-n modositott verzio, 10:00:00-s
modositasi idoponttal.

Ekkor mi tortent? Az, hogy B-n 10:00:05-kor keletkezett egy file
10:00:00-s utolso modositasi datummal, amibol azonban 10:00:03-kor
megnyitva meg a regi verziot lattuk. Eljen.

Vagy akkor a masik gepeken akkori modositasi datummal jelenne meg a file,
amikor tenylegesen atert a modositas? Azaz A gepen 10:00:00 ideju lenne
UGYANAZ a file, ami a B gepen 10:00:05. Ez igy jo szerinted?

(Szerintem azert nincs ilyen megoldas, mert ilyen inkonzisztenciat SENKI
nem akart csinalni. :) Ne word dokumentumokra gondoljunk, hanem barmilyen
alkalmazasra, ami mondjuk fileok lockolasan is mulik. A nagymama
fenykepeinek lehet, hogy jo egy ilyen filerendszer, de a sajatjaimat
peldaul mar biztos nem biznam ra.)

Olyan megoldas nem jo, esetleg, ahol a namespacen belul minden egyes
teruletet csak 1 felhasznalo modosithat, es mindenkinek van egy ilyen
terulete ("home"), de mindenki olvashatja mindenki maset?
(Persze ez feltetelezi azt, hogy az xyz.doc-ot ugy modositjak, hogy a
sajat reszukbe mentik el, es "megoldjak egymas kozt" a juzerek, hogy
"figyelj nalam van az ujabb verzio, azt masold le". Persze itt
szembetalalkozhatnak azzal a problemaval, hogy ketten mondjak ezt
egyszerre. De ezzel a gep is szembetalalkozhat, csak meg eselye sincs,
hogy eldontse, hogy mi a teendo, a felhasznaloknak talan van eselye.)


.SiCk of IT.
Horváth Ágoston János
2004-09-01 16:38:30 UTC
Permalink
Post by Sickboy
"Megoldjak egymas kozt" ?
Marmint kik/mik?
A felhasznalok.
Alapvetoen egy /home-rol van szo, ott azert nem szokas beleirogatni a masikeba.
Van ugyan egy kozos terulet a doksiknak, de azon belul eddig is
fennallt a problema, miszerint A user megnyit egy doksit, aztan
otthagyja, elmegy haza, masnap mar azt se tudja, mi is az egesz, de
elmenti, biztos, ami biztos. Ha meg kozben mas belenyulkalt, az
szivas.
Szoval ezt a problemat mar ismerik es lekezelik egymas kozt.
Jo megoldas erre az, hogy kotelezoen mindenki egyfajta editort
hasznal, ami tud lockolni alkalmazas szinten. Lejjebb ezt nem lehet
megoldani, mert kernel/libc az egeszbol annyit lat, hogy elobb az
egyik, majd a masik user hajt vegre egy open-read-close muveletsort
ugyanazon a file-on, az meg nem feltetlen helytelen.

Persze, utkozes eseten valaki megszivja (mondjuk dobhat hibat, aztan
majd elmenti mas neven, es megoldjak egymas kozt), a lenyeg, hogy amit
irtam, megoldhato, de tenyleg senki se pepecselt meg vele, pedig igen
jol jonne. Ujra felviragozna az nfsroot hajnala, esatobbi.
Sickboy
2004-09-01 19:55:49 UTC
Permalink
Post by Horváth Ágoston János
Jo megoldas erre az, hogy kotelezoen mindenki egyfajta editort
hasznal, ami tud lockolni alkalmazas szinten.
Es a lockolast hogy kezelned?
A "lockolas" tehat valami olyan muvelet, ami (megsem) 5 sec alatt terjed
el, hanem azonnal?
Post by Horváth Ágoston János
Persze, utkozes eseten valaki megszivja (mondjuk dobhat hibat, aztan
majd elmenti mas neven, es megoldjak egymas kozt)
Hogyan dob hibat? (Pont ez a kerdesem!!!)
Hogyan veszi eszre, hogy egy file valojaban mar megvaltozott, ha csak x
ido ("5 sec") mulva derul ki valojaban? Vagy ez a "kis hazard"
megengedheto a rendszerben?

Persze azt mar lehet mondani, hogy a file zarolas (a tenyleges file
tartalom masolassal szemben) minden hoston azonnal megtortenik, magyarul
csak akkor terhet vissza a flock(), ha az OSSZES nodeon lockolodott a
file, addig pedig all a program vegrehajtasa, es akkor itt mar be is jott
a network latency! Sot, igy meg sokkal nagyobb, mint ha csak 1 helyen (a
szerveren) kene lockolni.
Mondjuk erre lehet, hogy az a megoldas, hogy a lockok a szerveren vannak,
es az adatok masolgatasat meg megoldjak a nodeok egymas kozott, de ezzel
nem latom, hogy a file megnyitas muvelet mitol lenne gyorsabb, mint sima
NFSnel, hiszen igy is kell a szerverrel beszelni (lock). (Es azt mondtad,
hogy a network latency a baj, nem a nagy fileok merete miatti savszel
hiany, amit viszont lehetne csokkenteni nagyobb savszelu halozattal.)

A lenyeg, amit mondani akartam:

---
Egy elosztott rendszerben csak akkor tudod kikuszobolni azt, hogy egy file
open muveletnel network valaszra kelljen varni (akar azert, mert a file
nem helyben van, akar azert, mert ugyan helyben van, de csak akkor
nyithatod meg, ha a neten keresztul lockolod), ha lemondasz a file
muveletek idobeni konzisztenciajarol. (Amit elozo levelben kifejtettem.)
Erre pedig azt mondtam, hogy azert nincs vsz. ilyen megoldas, mert senki
nem akart errol lemondani.
---


.SiCk of IT.
Loading...