lassú megosztás

Hálózatok egyéb

adott egy pár gépes kis irodai hálózat és egy hálózati megosztásról használt program. a program sok kis pár megabájtos adatbázis fájlt használ. ha több gépről is igénybe van véve belassul az egész program.

eddig a szerveren futott virtual pc-ben egy freenas, ott sambaval volt a megosztás létrehozva.
samba "tuning" alkalmazásával sem sokat változott a helyzet, így át lett rakva a windows host gépre a megosztás közvetlen, de így is belassul.

nagy fájlok mozgatásakor nem jelentkezik lassulás a kliensek és a szerver között. csak ha kis fájlok és több gép felé. merre érdemes szerintetek elindulni a performance javulása érdekében?

  • 3874 megtekintés

( Dudu94 v | 2012. 10. 11., cs – 08:59 )

Hardveres megközelítés esetleg? Switch típus? (Remélem nem hub van :) )
Hálózati kártya sebességek?

Hááát nálunk néha 15-en is rácuppannak a sambán lévő több száz fájlból álló dbf temető ős dos progikra. Igaz sas winyók vannak a szerverbe. Én először megnézném nem-e a szerverben lévő winyó nem bírja a sok fejpozicionálást.

szerk: Mondjuk most nézem az egyik kommentben, hogy több perces várakozást ír, no azért annál többet tud egy desktop winyó is, nem ott lesz a gond. ...de nem is a sambával. Tudom, hogy nem szereted, de ennyit röhögve elvisz a samba.

Rózsár Gábor (muszashi)

1.4-1.6MB(!) volt az adatkupac. XP-s megosztásról percen belül összecsomagolta, feldobta a távoli backup szerverre az app. Ugyanezt szambáról bő 10 perc után le kellett lőni, mert sehol sem járt a melóval, még akkor sem, ha senki sem matatta a fájlokat. Erre tessen gombot varrni...

Igen, már olvastam a sztoridat pár szamba szapuló bejegyzésben korábban. :) Nem tudok rá gombot varrni és készséggel el is hiszem, hogy ott mi lehetett a gond tudja a fene. Valami oka volt, de ezt már nem fogjuk megtudni mi.
Az én tapasztalatom samba kapcsán egyszer kb 10 éves, ami az iskolai és kb 80 kliens, illetve egy 7 éve működő is, ahol viszont sok foxpros marhaság is van a tengernyi pdf, doc, odt, stb mellett. Még az abev is hálózati meghajtóról fut. Ez utóbbi helyen 80 Giga a mentés, aminek max a fele mél a többi az bizony a sambán csücsül saját és közös mappákban.
Tehát azért tud a samba jól is működni. (ha összeadom 17 év üzemeltetési tapasztalat :D) De ahogy néztem kolléga rakta már win-re is és ott is gondja volt, tehát a sambát ki is zárhatjuk.

Rózsár Gábor (muszashi)

( zeller | 2012. 10. 11., cs – 09:03 )

Ismerős szitu, a megoldás az volt, hogy szamba ment a kukába, az adatok meg egy Windows-os gépen lettek megosztva, és azóta van nagy öröm és bódottá.

Lehet, hogy a háttértároló ennyit bír?
Ha nem SSD van benne, én megpróbálnám azzal a lényegesen magasabb IOPS miatt.
Mivel a hardverről semmit nem tudunk, egyelőre megtartom magamnak a többi ötletemet. :)
Az adarbázisról is írhatnál pár szót, ott is lehet gubanc. 

openSUSE 12.2, vagy ami éppen jön.

hardver: 2,4 c2d a cpu, 2g ram, háttértár az sata-s mezei desktop hdd. általában 4-5 gépen fut egyszerre a program amikor a lassulás érezhetővé válik (1-2 másodperces betöltési idő 30-40 másodperc, de van hogy több perc lesz). a hálózat fast ethernet, az adatbázis dbase.

Az első, ami erről eszembe jut: halmozottan hátrányos helyzetű!
A processzor és a hálózat megfelelő lehet a célnak. A gépbe tolnék még RAM-ot, a HDD-t kicserélném (pl. OCZ Vertex 3, vagy 4) SSD-re.
A DBase-ről meg ne is beszéljünk, de gondolom, nincs más lehetőség.
A programról, ami az adatbázist használja... Gondolom valami régi DOS-os program a 80-as évek elejéből, amihez foggal-körömmel ragaszkodnak... 

openSUSE 12.2, vagy ami éppen jön.

Ember! Anno MFM diszkről, Arcnet-en simán mentek Clipperes programok minden gond nélkül, párhuzamosan - igaz, akkor Novell NetWare volt a szerver... Nem a vas a kevés alatta, hanem -ahogy itt-ott olvasom- az XP/Win7, mint kliens a probléma. (Az én szambás performancia-problémámat nem Clipper/dBase app okozta)

Vasat bővíteni egyszerű, de fölösleges addig, amíg ki nem derül, hogy CPU-ban, memóriában, diszk i/o-ban, vagy nyers hálózati átbocsátóképességben szűk a meglévő eszközpark.

Perverz lenne Mars-nwe a szerverre, és FreeDOS , mint kliens egy teszt erejéig? Szerintem határeset, de adnék neki egy lehetőséget...

Nem lehet, hogy nem a hálózattal, hanem a használt dbase/clipper/foxpro programmal van baj?
Indítsd el egy combosabb gépen, nem hálózaton levő adatbázis fileokkal 4-5 példányban, és ha így is belassul, akkor hiába javítasz a hálózaton.

Én inkább a szoftver hibájára tippelnék, ugyanis főleg az egyszemélyes garázscégek által gyártott nyilvántartóprogik/könyvelőprogik nem hálózati használatra készültek eredetileg, és ha a fejlesztő nem készült direkte hálózaton megosztott adatbázis fileok kezelésére, akkor bizony lehetnek bajok. Szerencsésebb esetben csak a sebességgel lehet gond, az általam tapasztalt esetekben bizony az adatbázis fileok is tönkrementek néha.

Ha teheted, cseréld le a progit vmi normális sql szervert használóra. DBase felett eljárt az idő minden tekintetben.

+1
Könnyen lehet, hogy a DBase-ben használt zárolási megoldás egyáltalán nem teszi lehetővé a normális konkurens használatot(pl: teljes fájlt zárol olvasásra és írásra is).

Nem hiszem, hogy ekkora rendszerben az SSD a megoldás. Mindenképp megnézném linelord helyében a DNS-t(legyenek regisztrálva a gépek), futtatnék egy teljesítmény monitort a szerver gépen. Továbbá csinálnék sok kis apró tesztfájlt és ezekkel végeznék hálózati tesztet. Ha itt minden rendben (másolás-megnyitás-szerkesztés-átnevezés-törlés), akkor 99%, hogy a DBase/program a ludas.

Apró megjegyzés... Gondolom, a több évtizedes program korábban (más szerver és kliens OS) teljesítményét tekintve jól működött (ha nem így lenne, akkor már esélyes, hogy kukázták volna).
Mivel a hálózat,meg a hálózati fájlrendszer kezelése az OS-ben van jó mélyen, szerintem ott van a bibi - amit sajna nem nagyon lehet megoldani, max. megkerülni.

korábban gyors volt, bár mindig is panaszkodtak a lassúságára. elvileg eddig senki nem tudott vele mit kezdeni. amikor először ránéztem a rendszerre én, akkor 256mb ram volt a virtuális gépnek, ezt feltoltam 1g-re, mert folyamatosan kihasználta ezt a rendszer, akkor jó lett egy darabig. később kikerültek a vm-ből a megosztások (samba lassúságra tippelve), a windows host gépre átrakva... nem sok javulást hozott. körülbelül 100 darab kis pár kilobájtostól az 5-6 megás fájlig vannak a dbase fájljai.

"korábban gyors volt" - kevesebb volt-e a felhasználó ill. a tábla ill. az adatmennyiség ?
Én továbbra is arra tippelek (lásd n.balazs hozzászólása), hogy a táblák sokáig vannak lock-olva, nem rekord szintű lockolást használ. A rekord lock-al meg az a baj, hogy windóz file share-en nem működik megbízhatóan (pl lásd SQLite - nekik is ugyanez a bajuk). Novell-en nem volt gond ezekkel, a samba-t nem tudom.

Valaki említette feljebb a Mars + FreeDos párost, lehet hogy azzal lenne a legstabilabb és leggyorsabb.

( linelord | 2012. 10. 19., p – 12:27 )

végül az UFS cseréje ZFS-re és még pár giga ram megoldotta a helyzetet :D

( legyes | 2012. 10. 19., p – 13:18 )

Nem lehet, hogy a megosztást biztosító gép egy kliens Windows, mint pl. XP? Mert akkor nagyon gyorsan bele lehet futni az egyidejű TCP kapcsolatok számának korlátjába.
Linux alatt bármilyen nem EXT2/3 fájlrendszer drasztikusan javított a sebességen. Az XFS például hatalmasat dobott a kis fájlok sambás kezelésén az EXT3-hoz képest. A RiserFS is jól hasított, de valamiért sok RAM-ot evett tőle a Linux. Modernebb/újabb/ritkábban használt filerendszerekkel nem kísérleteztem.