Abevjava + samba = lassúúú...

Hálózatok általános

(Remélem itt jó helyen lesz a totyik)

Sziasztok,

a probléma a címben :)

Kicsit bővebben:
Könyvelőméknél én rugdosom a rencert, és kitalálták, hogy legyen már hálózatos az abev + abevjava, mert az milyen jó.
Solaris 10 + samba, zfs mirroron csücsül a megosztott alkönyvtár. (vas: X2100M2, 5GB ram)
Egy nyomtatvány megnyitása (azaz a lista behozása) a klienseken (xp és win 2000, vegyesen) 1 perc körül van, ami rengeteg, idegőrlő... Mármint a használói szerint - elhiszem nekik, hiszen szinte percenként nyitogatják - nyitogatNÁK a bevallásokat.
Próbáltam sok paraméterrel játszani, de nem sikerült érezhető, igazán nagy különbségeket generálnom a betöltési időben...
A problémát nyilván az okozza, hogy az "abevjavapath"/mentes alkönyvtárban lennének a szóban forgó fileok, amik 2-3-4 és néhány tíz kb méret közöttiek, és most olyan 780-an vannak...

Jelenleg így néz ki az smb.conf-om, egyébként a "Solaris-szal szállított" samba-t használom, ha ez számít.

[global]
display charset = UTF8
domain master = no
local master = yes
preferred master = no
os level = 99
wins support = no
workgroup = WORKGROUP
Netbios Name = Solaris
server string = Solaris Server
log file = /var/samba/log/log.%m
max log size = 10240
# socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
# socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY
socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=65536 SO_RCVBUF=65536 IPTOS_LOWDELAY
load printers = no
ldap ssl = no
interfaces = bge0
invalid users = root
# veto files = .*/local.*/INBOX/INBOX.*
# hide files = .*/local.*/INBOX/INBOX.*
printcap name = /dev/null
load printers = no
lock spin time = 15
lock spin count = 30
read raw = yes
write raw = yes
kernel oplocks = yes
max xmit = 65535

[abev]
path= /abev
public = yes
writeable = yes
browseable = yes
create mask = 777
directory mask = 777
oplocks = yes

Esetleg valakinek van tapasztalata/ötlete?

Köszönöm, hogy elolvastad! :)

  • 6777 megtekintés

( vajtsz | 2009. 07. 30., cs – 07:28 )

Hát abev fele kitolto program sose szerette a halozatot, persze ugyf.szolg. szerint "meg senki nem panaszkodott" de en akarhany embert kerdeztem hogy "nalad is lassu az abev halozaton" "az hat" volt a valasz.

Lehet persze tuneti megoldasokat alkalmazni, olyan sorrendbe irom kb ami szerintem jo kiprobalni

1. Kliensbe tobb ramot pakolni ! eza java cucc jo jo caskhat virtual gep es kell neki a RAM minel tobb 512 Mb legalabb, aztan ha van ram akkor lehet tuningolni a setenv.bat ot :
@SET MEMORY_OPTS=-Xms128m -Xmx256m
Ez nalunk JELENTOSEN gyorsitja a progit !

2. Ha sok bevallas van akkor erdemes a mar valoszinuleg nem hasznalt bevallasokat archivalni, vagy egy masik abev ala attenni. Mert az okos abev indulaskor valahogy felolvassa az osszes bevallas fajlt, es valamiert azt olyan kib. lassan csinalja hogy percekig eltokol vele.

3. Ha az ugyfel torzsadatok kozott sok bejegyzes van, es sok felesleges akkor erdemes kiszemetelni, mert azok is lassitjak mint allat (szoveges fileban tarolja soronkent...)

4. Nalam az oplock (level2 meg minden oplock) kivan kapcsolva, de azse gyorsit rajta sokat sztem.

Mentesek konyvtarban nekem 2700 file van, archivum 1300, korabban keszitett bevallas megnyitas ablak ~10 perc, uj bevallas ablak ~perc. Dual Xeon, uw320 scsi hdd-k raid1 be...
Anno meg a wines abev et picit probalgattuk, ilyen muveletkor mindig vegigolvassa az osszes bevallas fajlt (smbclient legalabbis megnyitja, es olvassa) valsz torzsadatokkal probalja parositani, nemtom...

Amennyire en tudom win megosztason ugyanennyi adattal ugyanilyen fos lassu - FIXME !

Konyveloknek megkellett tanulni paralell feladatvegrehajtast, elinditjak regegl abevet, aztan picit meloznak mast :)

Ha viszont valami masra rajonnel akkor kerlek oszd meg velem az eredmenyt.
Lehet hogy mas tipusu telepitessel esetleg gyorsabb, bar nezegettem a telepitesi lehetosegeket es sebessegbeli elterest nemnagyon gondolom hogy okozhatnak, dehat kitudja..

Sziasztok!
Nem a hálózat miatt lassú, hanem mert bele kell olvasni minden fájlba, hogy azt a bizonyos betöltés listát összeállítsuk. Ez ennyi idő :(
Az a hash -es okosság elvileg azért lenne, hogy ha nem változott semmi, akkor gyorsabb legyen, de erre még rákérdezek.
Az nem megoldható, hogy userenként (könyvelőnként) külön mentések mappát csinálni? - ez megoldható a programmal. Vagy kell látniuk 1más munkáit?

2700 xml-t hogyan lehet sztetek pikkpakk felolvasni? Vagy lehetne a sima fájl tallózás, de akkor meg az lenne a baj...

Pontosan hogyan mukodne eza kulon mentesek mappa ?
Be lehet ugy allitani ABEV-et hogy tobb adat konyvtar legyen egy ABEV hez ?
Vagy ez ugy lenne hogy csinaljak halozaton tobb ABEV telepitest mas-mas konyvtarakba, es egyes felhasznaloknak egyiket, masikaknak masikakat tegyem fel.
Mert ez szerintem nemcsak azer nemjo mert neha bizony vanhogy mindent latni kene, valamint adminisztralni is horror egy ilyet szerintem.

Azt egyébként meglehet oldani hogy egy gépen 2 abev fusson más más adat könyvárral, attol fuggoen hogy milyen parancsikonnal inditom ? Ez arra lenne jo hogy csinalnank 1 ARCHIV abev progit, amibe idonkent atpakolasznank sok-sok bevallast ami mar nemnagyon kell, es igy az eles ABEV sokkal gyorsabb lenne. Regi ABEV el siman ment (Wines ABEV) viszont JAVA-s al nemnagyon megy ezse, hogykell ???

----------Megjegyzés-----------
Aztmeg nemertem miert nem lehet csinalni/karban tartani az ABEV program alltal keszitett fileokrol egy tablazatot (ne adj isten ne szovegfileban) hogy ne kelljen minden listazaskor az összesbe beleolvasni, hanem eleg lenne azt a kigyujtott fajlt megnezni. Elvileg minden filet az abev csinalja, nem ? akkormeg folyamatosan tudna szinkronban tartani a lista filet es a fajlokat.

Userenként lehet külön mentések mappát csinálni. Az ilyen adatokat userenként tartja nyilván a program. win alatt "documents and...\user\.abevjava\user.enyk" a fájl és a "prop.usr.saves=mentesek" a paraméter.
unix alatt nem vágom az indítgatást, de win alatt ha 2 user van, akkor ki-be jelentkezés után lehet 2 féle könyvtárszerkezet lásd fentebb. De 1 useren belül csak a parancsikonnal asszem nem lehet variálni.
A karbantartás azért nehézkes, mert "kézzel" is bele lehet nyúlni az adatfájlba és akkor ugrott a nyilvántartás. (az hogy olvasható legyen az adatfájl követelmény volt.)

---megjegyzes---

Ugy hogy a fo bevallas parametereket egy kulon allomanyban folyamatosan gyujtom, kulonben hasznalhatatlan az egesz....

Tudom, irtak hogy kintrol "kezzel" is belenyulhatnak a bevallasokba/fajlokba, de ettol en eltekintenek, nem kene kivulrol belenyulni, illetve kivulrol belenyulas eseten lenne 1 gomb programban azon "allomany"-t frissitene a felhasznalo aki kivulrol belenyult...

Szia!
Ez jó ötlet. Most is így van valahogy, csak a frissítés auto megtörténik, nem gombra. Valamit ezzel fogunk majd ügyeskedni, mert valahogy nem az igazi. Túl gyakran frissít - esetleg ok nélkül is.
Menni fog ez! :)
("Ettől én eltekintenék" - ja, így könnyű :) )

azért vannak olyan adatbázistípusok, amik ennél "lehelletnyit" gyorsabb elérést biztosítanak ;) meglehet nem a 2700, hanem az egyszerre és az xml volt ami nem tetszett csak :) sajna ez a program nem épp átgondolt tervezés eredménye (mondjuk nem csoda, a program "előélete" se mutatja, hogy valaha is sokat agyaltak volna a tervezéssel (abev2006...)).

--
xterm

( dj | 2009. 07. 30., cs – 12:30 )

Én is körbejártam a témát, mert egy könyvelőirodában igencsak felgyülemlett a bevallások száma.
Tehát:
1; a samba beállítások nagyon keveset javítanak. Amit érdemes még beírni az a következő (legalábbis nekem ezekkel volt a leggyorsabba a samba):
aio read size = 65535
aio write size = 65535

azt nem tudtam eldönteni, hogy 65535 vagy 65536 legyen ez is meg a max xmit értéke, mert mindkettővel működött és nem észleltem se hibát se teljesítménybeli különbséget.

2; nem lesz gyorsabb, ha win-es meosztásra van telepítve, még a titkos reqsizbuf 65535 beírásával a regisztribe sem. Sőt inkább lassabbnak tünt.

3; amivel igazán sikerült ezt a szutykot felgyorsítani az a következő:
van egy tmp könyvtár az abevjava telepítési könyvtárjában, ott ahol a mentesek meg az archiv könyvtárak is vannak. Ebben a könyvtárban létrehoz minden felhasználónak egy hash file-t, külön a mentesek-re és külön az archiv-ra is. Na most, minden egyes nyomtatvány megnyitásra, vagy az archiv megnyitásra, újraképzi, vagy legalábbis végigellenőrzi ezeket a fájlokat. Na ez tart sokáig.
Azt nem tudom, hogyan lehet ezt a hash file buzerát kikapcsolni, gondolom sehogy, arra se jöttem rá, hogyan lehetne ezt a tmp könyvtárat a kliensekre tenni. Egyet tudtam csinálni, elrontottam a konfigfile-t, hogy ne találja meg ezt a tmp könyvtárat.
Nem tudom, hogy ha nincs ez a hash file, akkor annak van-e valamilyen káros következménye, de inkább visszaállítottam. Biztos ami biztos.
Ha van valaki aki mondjuk a fejlesztőket ismeri, vagy van egy ismerőse aki ismeri a fejlesztők ismerősének az ismerősét, jó lenne ha megkérdezné, vagy jelezné feléjük a dolgot, mert az apeh felől ez reménytelen.

Ja, a megoldás:
c:\Document and Settings\felhasználó\.abevjava\felhasználó.enyk
Ebben kell a prop.usr.tmp=tmp sorba kell valami hülyeséget írni pl.
prop.usr.tmp=c:\temp
Ekkor megnyitáskor hibát ír a dos-os ablakba de villámgyorsan nyitja a könyvtárat.

Uff

Kiprobaltam, valoban ha hulyeseget irok a TMP helyere akkor a fenti felallasban nalam 3 perc lesz a ~10 bol :) nemrossz :)

De azert ense merem igyhagyni, fenetudja mire hasznalja azt a filet....
Egyebkent ha hulyeseget irok TMP konyvtar nevenek akkor a kis fekete consol ablakban a konyvtar scannelesnel egy errort dob hogy nem talalja a konyvtart, es utana cosnolra irja a tobbi okossagot. Lehet hogy csak azokat irna ki fajlba (meg meg valamit) amit ott consolba ir... dehat fenetudja...

( aspirin v | 2009. 07. 31., p – 10:44 )

Először is köszi mindenkinek az infókat, ezek szerint az ~1 percünkkel olyan rosszul nem is állunk... :)
Másrészt... valami rendes szoftvert is reszelhetnének az apeh-nél, nem egy ilyen sz.rt... grrrr... :(
<-------
You can't grep on dead trees.

Ja... :)

Mondjuk azon filóztam ma, ahogy olvasgattam a topicot, hogy
- azért (khmm... mondjuk úgy) nem olyan nagyon átgondolt a szoftver - és ezért lassú -, mert nincs pénz, és nem igazán jó programozókat foglalkoztatnak
- vagy jó emberanyag lenne, aki ennyiért (nemtom mennyi) viszont nem veri agyon magát a melóval; néha taszajt rajta egyet, aztán jóvan...
(Én is közalkalmazott vagyok, sokmindent láttam már... ;))

Mindenesetre ezt hívom "tipikus magyar megoldás"-nak:
1: van jó ötlet (mondjuk itt a java)
2: van jó ember is aki megcsinálná (még az is lehet hogy ott sündörög valahol a project környékén)
3: megcsinálják (sokszor elég sok pénzért!!!)
4: aztán valami apróság miatt (mondjuk, hogy most a hálózatos használat lassúságára gondolok) mégis olyan "magyarosan" szar lesz.

Hátha egyszer lesz pénz... :)
<-------
You can't grep on dead trees.

" van jó ember is aki megcsinálná"

Szerintem egy ilyen messze elkerülte ezt a projectet, ugyanis eleve xml-ben tárolni az adatbázist, meg induláskor 2700 xml-t beparsolni olyan pistikés dolog....
Biztos dbase-ben programozott régen, aztán 1 hónap alatt átképezte magát java szekemberré, és xml howto-t dobta neki a google elsőre "java adattárolás" keresőszavakra... Kb. igy tudom elképzelni, de kijár neki a faszkorbács, meg a szívlapáttal tarkónbaszás.

...ugyanis eleve xml-ben tárolni az adatbázist...
Fontos leszögezni, hogy jómagam nem vagyok programozó.
De...
Ha az ember foglalkozGAT egy kicsit mélyebben az informatikával, azért rájön, hogy adatok tárolásának nem mindig a fájlok egyesével elrakosgatása, majd később, ha kell, egyesével visszaolvasása a leghatékonyabb módja.
Asszem ez itt a dolog nagyon gyenge pontja.

de kijár neki a faszkorbács, meg a szívlapáttal tarkónbaszás.
Ezen nagyon röhögtem... (elég vizuális tipus vagyok :))

<-------
You can't grep on dead trees.

Nem adatbázist, hanem nyomtatvány adatok. Igen lehetett volna esetleg adatbázisban is, nem úgy lett... A régi abev pl. bináris fájlban tárolta a bevallásokat. Akkor meg az volt a baj, hogy nem olvasható a mentett adat, biztos kémkedik az apeh. Mindig lesznek okosabbak, jobb programozók, "éleslátóbbak". Az hogy "olvasható formátumú" legyen az adattárolás követelmény volt a programmal kapcsolatban. Olvastatok már könyvelős topicot az abevről? Javaslom esetleg. "Jaj, hol vannak a bevallásaim..." még így is, hogy hívhatják xy_0853_20090304 -nek is a fájlt. Szóval nehogy azt higgyétek, hogy olyan 1xű ez.
És ne kezdjük már megint ezt az "1 hónap alatt jobban megírtam volna" dolgot, mert van kb. 2millió kérés, igény, akadály, amit figyelembe kell venni 1 ilyen programnál.

( vajtsz | 2009. 08. 12., sze – 12:40 )

A sok flame helyett nemi epito jellegu hozzaszolas kene inkabb sztem :P (tiszt.kiv.)

1. ABEVJAVA ban van eza Szerviz/Adatok archivalasa-visszatöltése menüpont, ott a nagyon ritkán használt sok sok bevallás fájlt lehet archiválni programmal, es szep szurt formatumban tud user egyenkent is akar visszatenni egy-egy bevallast aktivak koze. Ahogy en neztem az ARCHIV mappat nem nezegeti term. vegig sima bevallas megnyitaskor, szoval ez gyorsitja a cuccot.

2. Ha valakinek megsem tetszik ezaz archivalgatos moka, akkor csinalhat egy masodik ABEVJAVA-t az ARCHIV bevallasoknak. Vagy egy kulon win user accon, de megoldhato egyazon USER accon belul is ketto, csak akkor inditaskor cserelgetni kell a windir/abevjavapath.cfg meg a %homedir%/.abevjava/%user%.enyk filet annak megfeleloen hogy milyen kornyezetet akarunk inditani. (otlet by SzIS !)

Persze nálunk is alkalmazzuk az archiv-ot, de az ugyanolyan lassú, és annak is csinál temp-et, sőt az üres bevallásoknak is. Sőt még a helpnek is ???? Ha felteszik az összes nyomtatványt (láttam már ilyet), az ugyan úgy be lassul, mint a kitöltött nyomtatványoknál. Egy egyszerűnek tűnő új nyomtatvány megnyitása egy évszázad. Kénytelen voltam kigyomlálni a nemhasznált nyomtatványokat és fejvesztés terhe mellet nem szabad felrakni az összeset, hiába egyszerűbb.
2. megoldás szintén nem jó, mert attól még, hogy külön teszed az archivot, az még lassú lesz ha meg kell nyitni, akkor mit segít. Meg kicsit macerás.
Inkább egy jobban működő programot kellene írni.
Hozzáteszem az előző abev2006-os program (mielőtt lehurrogtok, ez volt használatban 2008 év végéig) szintén iszonyú lassú volt hálózatos használatban.
Konklúzió: nem gondoltak arra, se most se ezelőtt, vagy legalábbis nem tesztelték ki rendesen, hogy hogyan működik az abev program hálózatban.

Az érdekes mert nalunk is fennt van par bevallas típus es amikor új bevallast nyitunk AZONNAL bejön az ablak...

1. En leteszteltem, csinaltam 2 abev telepitest, egyikbe volt 1900 archiv, es 2900 eles bevallas, masikban pedig csak ugyanazon 2900 eles bevallas, es a bevallas megnyitas ugyanannyi idobe telt, ergo ARCHIV mappat nem olvassa sima megnyitaskor. De java consolban irja hogy melyik mappat scanneli, es csak MENTES mappat irja, archive-t nem !

2. Ha csinálsz 2 ABEV et akkor nyilván az ARCHIV abev lassú lesz mert oda pakolászod át minél előbb a régi és sok bevallást, de olyanokat kell csak elrakni amit szinte sose nyitnak meg utolag, vagy csak néha néha egyet valamiert (08 pl. vagy ilyenek) szóval igaz hogy archiv lassu lesz, de eles meg gyorsabb sokkal es aza lenyeg. De szerintem elso megoldas is ugyanilyen jo.

Hát ez nem egy combos adat :)
Na szóval, én nem írtam, hogy mindig végignyálaz mindent. Hanem azt, hogy mindennek csinál temp-et. Az archiv-nak, a mentések-nek, a nyomtatványoknak, mindennek. Értelem szerűen mindig azt nyálazza végig, amelyiket meg akarod nyitni. Természetesen mindent pakolunk az archivba, de ott olyan sok bevallás van már, hogy egy örökkévalóság mire megnyitja. Sajnos elég sokszor előfordul, hogy egy archivált nyomtatványt kell megnyitni. Gondolhatod.
A lényeg a lényeg, hogy ez a program egy selejt. Nem így és nem ilyen sebességgel kellene működnie.

"A lényeg a lényeg, hogy ez a program egy selejt. Nem így és nem ilyen sebességgel kellene működnie."

Ezzel egyetértek, és aza legszomorubb hogy mar az elődje a WIN es ABEV nel is ugyanez volt, igy plane erthetetlen az egesz...

Mindezek mellett nemvagyok benne teljesen biztos hogy a kodolo programozo a hibas - mert ha aztmondta a prg tervezo (vagy akarminek is csufoljak most) hogy biza az adatfajlok azok barmikor valtozhatnak, es azokat mindig felkell olvasni hogy eppen mivan akkor a hiba az O keszulekeben van.

De tenyleg egy hulladek...

( dj | 2010. 02. 09., k – 22:00 )

Felélesztem a topicot ha nem baj.
Egy kis workaround, hátha valaki hasznát veszi a szerencsétlenkedésemnek.
Tehát új év új kihívás az abevjava életében. Mivel 2006 ban úgy gondolták a fejlesztők, hogy nem csinálnak minden évben új verziót és ezt a jó szokásukat követték az abavjava-val is, ezért ugye felmerült az igény, hogy csináljunk(jak) egy szűz 2010-es évet. Az abevjava egy samba megosztásra van telepítve több ezer bevallással, lásd régebbi hozzászólásokat. Mivel az újratelepítés nem működik, mert akkor a telepítő felülcsapja a felhasználó beállításait, és akkor nem tudja használni az előző évet, egy kis trükköt kellett alkalmazni. Az apeh honlapon vagy egy leírás, hogyan lehet cégenként különválogatni, tehát, hogy minden cégnek külön abevjava induljon. Ezt dolgoztam át évre.
Tehát:
megosztáson levő 2009-es könyvtárat átmásolni 2010-esbe, kitörölni az archiv a mentesek és a nyomtatványok könyvtárban levő állományokat.
Létre kell hozni egy .enyk fájlt. pl. 2010.enyk ez az új 2010-es könyvtárba kell hogy kerüljön
A tartalma ugyan az legyen, mint a felhasználók .enyk-ja (C:\Document and Settings\felhasználo\.abevjava\felhasznalo.enyk). Az ebben szerplő útvonalakat át kell javítani a 2010-es útvonalakra (4 darabot)
Nálam ez pl. U\:\\userdok\\abev 2009\\naplo ezt kell átírni az új útvonalra.

ha ez magvan akkor létre kell hozni egy pl 2010.bat parancsfájlt, szintén az új könyvtárban.
Tartalma nálam:

u:\userdok\abev2010\abevjava_star.bat "userprofile=u:\userdok\abev2010\2010.enyk"

Ezt a parancsfájlt kell a felhasználóknak kitenni parancsikonra és van egy szűz 2010-es abavjava. Nem árt ha minden felhasználónál ugyanarra a betűjelre van becsatolva a megosztás. Nálam éppen U:\
Leírni tovább tartott mint megcsinálni.

( slinky v | 2010. 02. 27., szo – 17:44 )

Attol az user homeban levo filet meg felolvassa, es a szar utvonalon levo konyvtarat hasznalja ;)
viszont startupkor odalehet masolni amelyik kell neki.

UPDATE: useroptionfile=/foo/bar ok

( zeller | 2010. 02. 27., szo – 18:54 )

Újabb egy-két fájlnál többe belerosál a szamba című sikertöténetet olvashattunk. Nálam is az volt a megoldás, hogy a szamba nagyívben repült, és a 2 darab 10k-n pörgő sata-II diszkből készült tükör azóta csak mint backup terület funkcionál, az 5400-on kerregő, agyontöredezett fat32-t használó Windows XP-ről kiajánlva a cucc adatfájljait döbbenetesen gyors lett az egész - agyonverte az alkalmazástesztben az ócska gép, ócska Windows-os sahre a szambát.

Volt alatta... most epp ext3, de lehet xfs lesz belole meg sok ram agressziv cacheles mellett. viszont nem a fst erzem szuk keresztmetszetnek.... En meg tanultam kodot es adatbazist optimalizalni, minden apro sebessegert megszenvedni... siman megkoveznem aki ez az appot igy kiadta a kezei kozul... nincs baj az xmlel mint interchange format, de azert nem a filerendszert kene adatbaziskezelonek hasznalni...

az bajom ezzel, hogy fikázni fogod azt, hogy sokaknak ennél többet tud a samba. ezért ezt nem is írom, oly mindegy. viszont lövésem sincs mitől csinált neked 150kB/s átvitelt a samba, mert ennél bőven többet tud. az abevjava viszont szar. nekünk samba (solaris) van az abevjava alatt, de ennél lényegesen jobb paraméterekkel (nem értük el a "user-timeoutot").

--
xterm

Fúú, micsoda párbeszéd lett itten a totyikban :)
Mi is Solaris alatt sambázunk, az IO nálunk is teljesen rendben van (nem mértem, de "szemre" nincs gond), az abevjava meg tetű.
Viszont - mivel SXCE van a vason - kipróbáltam a Solaris saját smb-jét is ( bővebben róla itt ), ami elvileg kernel-szinten sambázik, de az abevjavát nem hatotta meg, maradt a teljesítmény a béka segge alatt (*)...
szerk: (*) - pedig a Sun (béke poraira!) együtt reszelte össze az MS-sel a Solaris CIFS szervert. Lehet, frissíteni kéne, és újra megnézni a teljesítményt :).
<-------
You can't grep on dead trees.

Nyers fájlmásolásban valóban többet tudott, az alkalmazás-teszten vérzett el, de nagyon -- nincs mit szépíteni. Ha gondolod, előkaparom az alkalmazást, alárakhatsz tetszőlegesen hangolt/kireszelt szambát, és megpróbálom az app saját mentését lefuttatni. Ha a jelenlegi natív share-hez hasonló, vagy jobb lesz a performanciája, akkor megkövetem a szamba fejlesztőit, de addig sajnos nincs mese: a tapsztalat biza az, hogy sok apró fájlon matató cucc esetében gyenge - hogy finoman fogalmazzak.

(De jó, hogy nem nekem válaszoltál, így tudtam szerkeszteni a hozzászólásomat :))
Mellesleg mondasz valamit, mintha ilyesmi feltűnt volna... Egyébként azt gondoltam volna, hogy a zfs agresszív cache-elése ezen segít... de úgy tűnik, nem.
<-------
You can't grep on dead trees.

elhiszem, hogy van ilyen tapasztalatod. viszont élnék a gyanuperrel, hogy egy eléggé sok sebből vérző "program" (pl. abev) nem épp jó referencia. ugyanis elképzelhető, hogy nem (csak) a samba a szidni való alatta (bár a párbaállításod alá is támaszthatja. ha akarom).

--
xterm

megorultem amikor irtal mer gondoltam gyorsan kiprobalom WIN Xp prof az az Abev et mert atomgyors lesz...

Sajna nem jött be, igaz en NEM Fat32-n probaltam mert az sztem nem mai fajlrendszer es azer nemi biztonsag nem artana, szal NTFS-en volt az XP vel kiajanlott mappa...

7505 darab bevallas van ABEV alatt

XP kiajanlason mert eredmenyek megnyitas ablak nyitasakor:
1. 4 m 13 s
2. 4 m 13 s

Samba (lenny es APT ben levo samba)
1. 4 m 8 s
2. 4 m 4 s

Tudom hogy tobbszor kellett volna merni stb stb, de a lenyeg hogy sajna win xp megosztassal se gyorsabb sokkal mint samba.
Szegyen hogy egy orszagos bevallas kitoltoto program ha vanbenne ~7500 bevallas akkor rakattintok bevallasra es 4 percet "var"....

ebben igazad van, de már elég régen ez a helyzet (nézted már amúgy helyi filerendszeren és elégedett voltál a teszttel? :) mert akinek használni kell, az nem elégedett ott se), akár adaptálhatták volna, vagy kijelenthették volna, hogy az úgy biza nem üzemszerű működés. nem tették, ergo, eséllyel nem lehet kizárni a hálózatos működését.

--
xterm

Az "uj" abevjava rendszer HÁLÓZATOS telepítésére emlékeim szerint 3 féle módszer van, és ez apeh.hu oldalon publikált doksi.
Kulon van "telehazak" szamara biztositott anonym halozatos telepitesi lehetoseg, meg ilyen atomfontos dolgok.
Ebbol kiindulva gondolná az ember, hogy akkor halozatos mukodes tamogatott.

Egyebkent a ~7500 bevallas nem ugy lett, h en marha a szukseges 10et 750 peldanyban lemasoltam, hanem itt ennyi van ! es nem egy atomnagy multirol beszelek...

Persze lehetne ugyhogy mindenki telepitene a desktopjara sajat abevjavat, es akkor gyors lenne mint atom, viszont mentes=0 (vagy horror bonyolult) vagy biztonsag=0.

De persze hiaba futtatjuk itt a dolgot, megoldas nem lesz ebbol, szal nem ragozom.

( itan | 2011. 06. 30., cs – 22:04 )

Ha valakinek még aktuális a téma, egy kis segítség az apehtől(nav-tól) memóriakezelés kapcsán...

PDF-ben.

Újrakezdeni nehéz, feladni lehetetlen...

( uid_2716 | 2011. 06. 30., cs – 23:08 )

Nahát, hogyan csúszhattam le erről a témáról?

A probléma nyilván az, hogy a szinkron file-kezelési API alá nagy válaszidejű hálózatot rakni irdatlanul meglékeli az absztrakciót. A klienst a tünetek alapján egyértelműen helyi file-okra tervezték, szinkron működésre. Vagyis a kezdeti felnyalásnál a program addig nem kéri a következő file-t, amíg az előző meg nem érkezett, jóllehet tudja, hogy szüksége lesz mindre. Mivel a file-ok kicsik, a csövet a round-trip alatt lényegében végig üresen tartja.

Ezt a problémát látjuk visszaköszönni egy csomó helyen. Például alkalmazásszerverben (vagy ne adj' isten, kliensen) futtatott válogatási logika tárolt eljárás / nézet helyett, vagy bármilyen, kicsi fájlokkal hálózati fs-en szinkron módon dolgozó program. Még egy példa: IMAP szerveren futtatott keresés helyett MUA-ban futtatott keresés. Még egy példa: könyvtárszerkezet letöltése scp-vel/sftp-vel, kontra 

ssh ... tar -c ... | tar -x

.

A megoldás természetesen az, hogy a szinkron hozzáférést igénylő műveleteket a lehető legközelebb visszük az adatforráshoz. Ami ennél távolabb van, ott kötegeljük a kéréseket, és a válaszokat / hibákat is kötegelten dolgozzuk fel.

Az abev esetén ezt úgy lehet megoldani, hogy a java-s klienseket mind egy központi gépen futtatjuk, lokális file-rendszer felett, és a grafikus kimenetet (X11, rdesktop, vnc stb.) forward-oljuk. Ha a hegy nem megy Mohamedhez...

(Természetesen nem megoldás, hiszen a java-s kliensek ill. az XML parse-olás CPU igénye pillanatok alatt szét fogja zabálni a szervert.)

Azért azt ne felejtsd el, hogy egy többlemezes szervert gigabiten elérve nagyobb i/o sebességet érsz el, mint egy darab local sata diszkrol, tehát a mondandód első része akár még baromság is lehet.
Nem ma látok elöször számítógépet, de guru sem vagyok, talán ezért nem értem, pontosan mit is jelent ez:
"Mivel a file-ok kicsik, a csövet a round-trip alatt lényegében végig üresen tartja."

Milyen csövet, milyen round-trip?

Merthogy a samba így működik?

Igen, pontosan így működik, ha a kliens oldaláról így hajtják. A kép tökéletesen szemlélteti, mi történik.

A függőleges tengely az idő (valós idő, amit az óra mutat.) A "round-trip" az az idő, ami a request feladásától az arra adott válasz megérkezéséig telik el. (Oda-vissza, ping-pong, stb.)

Amikor megnyitsz egy file-t, beolvasod, lezárod, aztán mész a következő file-ra, akkor az alábbi történik: egy round-trip a file-rendszerig az open(), 1 db a read() (feltételezve, hogy kicsi a file és a legelső pong-ban át tud jönni az egész), meg egy db round-trip a close(). Ez igaz akkor is, ha a round-trip nagyon kicsi (helyi file-rendszer), meg akkor is, ha ehhez képest hatalmas (hálózaton megy).

A huncutság ott van, hogy a második file olvasásával egyáltalán nem kell megvárni az első file feldolgozásának teljes befejezését. Ez a felesleges várakozás látszik a bal oldali képen. A jobb oldali képen azt látjuk, amikor az összes, rendelkezésünkre álló információt kötegelve küldjük el a szervernek. Az utóbbi esetben egyetlen round-trip (egyetlen file feldolgozása) pontosan ugyanannyi ideig tart, mint korábban, azonban a round-trip-ek egymással át vannak lapolva. Emiatt az időtengelyen a távolság az utóbbi esetben sokkal kisebb.

Amikor a teljes round-trip nagyon rövid (helyi file-rendszer), akkor nem nagyon számít a dolog.

(Egyébként még ez sem igaz, mert a helyi IO scheduler is sokkal jobban tud működni, ha nagyobb rálátása van a program szándékára. Például van nyitva 512 file-od, mindegyikből kell 1 blokk, és hideg a cache. Ha sorban olvasod be a blokkokat, akkor a programod addig egyszerűen nem fogja az X+1-edik file-ból kérni a blokkot, amíg az X-edik olvasása be nem fejeződik. Így az IO scheduler-nek esélye sincs felismerni az optimális fejmozgatási mintát. Ha azonban összeraksz egy 512 elemű aiocb tömböt, és egyszerre odavágod a kernelnek egy lio_listio() hívással, akkor egy kellően fejlett ütemező a különböző diszkekre vonatkozó olvasásokat párhuzamosan fogja beindítani, diszken belül meg minimális fejmozgást fog megállapítani.)

A samba természetesen ki tud szolgálni valamekkora számú file-elérési kérést párhuzamosan, ezért a kliens által kikényszerített, file-közti sorosítás teljesen felesleges; az egyetlen érv, ami mellette szól, hogy így egyszerűbb a klienst programozni. Különösen a kötegelt hibakezelés tud szemét lenni -- például a szokásos exception-kezelés azonnal megbukik, mert a válasz-tömbben lehet 12 sikeres olvasás és 4 IO error. A hiba itt adat. Ezt fel lehet ismerni, és lehet belőle kézzel exception-t csinálni egy wrapper class-ban ("legalább 1 hibás válasz volt"), de alapból máshogy kell hozzá gondolkozni, mint a szokásos file-feldolgozásnál. Észre kell venni minden lehetőséget a párhuzamosításra (= a logikai függetlenséget a request-ek között), és explicite át kell adni a következő rétegnek.

Az elv független attól, hogy HTTP pipelining-nek hívjuk, vagy aszinron, kötegelt feldolgozásnak, vagy aio-nak.

Szerkesztés: ha az adott kiszolgáló történetesen tud read-ahead-et, az is csak akkor segít, ha 1 db nagyobb file-t olvasunk végig. A szervernek nem nagyon lehet heurisztikája, hogy az X. után mi lesz az X+1. megnyitandó file.