Sziasztok!
Adott egy probléma, amivel lassan 1 éve nem tudunk mit kezdeni kollégákkal. Építő ötleteket, tapasztalatokat kérnék.
Virtualizált környezetben, adott egy Samba-AD, ami file szerver szerepet is betölt. Windows kliensek dolgoznak megosztott meghajtókkal, külön jogokkal.
Adott egy program, nevezzük most Ügyeskének, ami minden kliensre fel van rakva és a file szerveren használ pár adatfile-t, aminek a formátuma SQLite.
Ha ez a file a gépeken a helyi ssd-n van, akkor gyors a program. Amint felkerül a megosztott meghajtóra, akkor látványosan belassul. Ezt produkálja akkor is, ha 1 felhasználó csatlakozik csak rá.
Amiket már próbáltam:
- jogosultságok variálása (local admin, domain admin)
- samba hangolás (lock-olás, debug, stb...)
- kliens csere (gép és tiszta windows)
- switch csere
- szerver bővítés (ssd-ről nvme-re, 1Gb-ről 10Gb-re)
- ha ebbe a virtualizált környezetbe felrakok még egy Windowst, amit bridge-ben összefogok az AD-val, akkor sem történik gyorsulás. Ha kimásolom ott is a helyi meghajtóra, akkor működik.
Minden más, ami a hálózaton van rendesen működik.
Ügyeske .net-ben van írva (elvileg), .net framework 4.0.30319 használ.
Több ismerőst kérdeztem már Ügyeskével kapcsolatban, de mindenhol hasonló a probléma.
A fejlesztő tanácsolta, hogy "NAS-on jól működik", de sajnos nem. (Igaz azzal az informatikussal, akivel teszteltette minden rendben volt. Összedugta a NAS-t a géppel egy az egyben és akkor elvileg gyors volt....)
Ami "megoldás" eddig van: Windows RDS és a program a helyi meghajtón van.
Ki merre indulna el?
Hozzászólások
SQLite egy egyfelhasználós adatbázis "kezelgető" engine. Szerencse hogy megy megosztott meghajtón, azaz legalább a file lockolás le van kezelve. Ami hiányzik belőle ahhoz, hogy több párhuzamos felhasználó hálózaton keresztül valóban használni tudja: párhuzamosság, dedikált memória cache, több fájl használata, stb. Azaz minden amiről az adatbázisrendszerek tervezése könyvben 20 éve írtak.
Ezen SSD sem fog segíteni, amikortól több "rekordot" (mondjuk 1-2000-nél többet) elkezd index nélkül pisztergálni, pláne hálózaton megvalósítva az fseek műveletet, meg fog halni. Megy, de annyira lassú... Helyi megoldásként fog menni, RDP lesz a barátod. Szerintem.
"Amint felkerül a megosztott meghajtóra, akkor látványosan belassul": mondasz egy lokális és egy hálózati tipikus időt? Mondjuk Ügyeske login vagy a legfontosabb lista lekérése mp-ben.
Ami lokális gépen folyamatos működésnek mondható (<1 mp), az hálózaton 2-5 mp. Van amikor egy menübe való belépés is több másodperc...
Ami furcsa, hogy olyankor a Windows is csak "teker" (program nem válaszol). Windows 7-nél még .net 2-es verzióval még nem volt ennyire lassú. Windows 10-nél egyre lassabb. Volt amikor az volt a válasz Ügyeske szüleitől, hogy xy Windows frissítés (ami fent sem volt a gépen) okozza.
Nekem nincs már ötletem, és lassan már energiám se kínlódni.
Ez valami egyedi fejlesztés? Ha minden kliens és a szerver is mindig Windows, akkor nem lenne egyszerűbb áttérni SQL Expressre?
Könyvelő program. Ügyfeleinek nagy része 1 gépes környezet, nem akarnak adatbázis szerver szintre lépni.
Ügyfelem könyvelő iroda, nem akar programot váltani.
Én meg nem akarok már középen állni...
Ezek szerint 1 db SQLite db / user, vagyis nem közösen használják? Mert akkor hirtelen működhet egy olyan, hogy ügyeske indulásakor egy helyi másolat a szerverről, a futás végén pedig másolás vissza.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Lehet, én is ismerem Ügyeskét :D – ez egy bevált megoldás.
Ügyviteli, konyvelo rendszernel elvben mukodik, gyakorlatban evi 240 napbol lesz 3-15 olyan, amikor elfelejtik es akkor odavesz vagy kesik a mar felrogzitett adat. Oka lehet hogy gyorsan lecsukja a nofebookot es hazaszalad vele. Tudom policy, de ezeknel a cegeknel meg irodariaszto es porolto sincs, nem hogy it policy.
Hát, ha sambával nem működik, akkor betenném a fájlt valami verziókövető rendszerbe, és megtanítanám az embereket, hogy lock+checkout után lehet a lokális gépen módosítani, commit után meg élnek a változások és valaki más jöhet.
Valami olyasmi rendszert keresnék, amiben mindezt egy webes felületen meg tudják csinálni a népek.
Ha valaki épp elfelejti, majd a következő (aki látja, hogy lockolt és ki által) odaszól neki, hogy fejezze már be, mert mások is dolgoznának ám.
Így meg van oldva a helyi másolat (elvárt sebesség) és a konzisztencia.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Te ezt komolyan működőképesnek gondolod? :D
Hogy a könyvelők majd SCM-be rakosgatják az adatbázis file-okat?
Másrészt a verziókövetők egyáltalán nem arra vannak kitalálva, hogy nagy bináris file-okat kezeljenek.
Persze. Sokan dolgoznak pl. MS Sharepointtal, pont így, ahogy leírtam. Akár könyvelők is.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Ha meg tényleg egy gép/egy user és csak a mentéssel van a gond, akkor tedd a kliensre és kapcsold be a file history-t és irányitsd a nas-ra. Pont ugyanolyan mentés lesz róla (csak, ha változik a file), mintha a nas-on mentenél és ha inkonzisztens az adatbázis, miközben nyitva van a program - amit kétlek - akkor igy is, úgyis inkonzisztens. Ha a laptop lecsukás a gond, akkor is ugyanaz lesz a végeredmény, ha ilyenkor inkonzisztensen hagyja, akkor az is maradna a nas-on mentve is.
De nem hinném, hogy egy sqlite-nál ilyen előfordulna.
Van egy közös adatbázis, amiben minden ügyfél alapadata szerepel. Ezen kívül ügyfelenként van 1 db file (számlázó,bér,egyszeres, kettős, deviza könyvelésre) cégazonosítóÉVSZÁM formátumban. Ha a program le tudná kezelni, hogy addig ne tudja más használni azt az adatbázist, akkor ez lenne a legjobb megoldás (adatbázis szerver nélkül). De így egymásra is tudnak könyvelni...
Nem lehet egy powershell szkriptel megoldani a lock->clone->progam indit->update->unlock workflow -t? Igen, ha valaki "leszakad" a szerveren lockolva marad a fájl, de ettől legalább látványos az adatvesztés veszélye, és létezhet rá powershell megoldás.
Ha az ötletedet összeraknák egy lokális gépre való másolással, már működőképes lenne vele a munka.
Jelenleg, ha hozzányúl egy file-hoz, akkor létrehoz egy ideiglenes adatfile.lock kiterjesztésű file-t. Samba debug szerint van amikor másodpercenként ezt 26x.
A clone lépés lenne a lokális másolat létrehozása, az update pedig a távoli fájl frissítése a lokális másolatból :)
Bocsi, ha nem voltam egyértelmű.
+1
Mielőtt nagyon szidnánk az adatbáziskezelőt - melynek azért meg van a saját helye, és ott igencsak sikeres - érdemes elolvasni az alábbi irományt: Appropriate Uses For SQLite, főleg a checklist részét.
Tudom: ami kerek, azt cipeljük; ami meg szögletes, azt meg gurítjuk. Aztán meg csodálkozunk, hogy nem vagyunk hatékonyak.
Az más kérdés, hogy a fejlesztő mennyiért készít az egyfelhasználós, egyszerű kis programjából egy többfelhasználós, kliens-szerver architektúrájú szoftvert. Lehetőleg ingyen, mert a kibicnek semmi sem drága.
Update - most látom, hogy már más is belinkelte.
AL
Ha SQLite mellett maradtok:
1. A fejlesztőnek kutya kötelessége remote setupban is tesztelni a programját, kb hasonló felállásban (tényleg remote kliens-szerver és nem virtualizált teszt környezet).
1.a. Ha ott jó, akkor addig közelítse a setupot (hardver, konfig(!!!)) a tiedhez, amíg elő nem jön a probléma, akkor goto 2.
1.b. Ha ott már nem jó, akkor goto 2.
2. Próbálkozni kell SQLite adatbázis szinkronizációs beállításokkal.
- A fejlesztő adjon kapcsolókat, amivel az SQLite synchronous, ill journal_mode flagjeit tetszés szerint állíthatjátok, végigpróbálva az összes kombinációt.
Tippem: nem használnak WAL-t, vagy azt szuboptimálisan használják, és minden DB írást követ egy fájl rendszer flush + szinkronizálás, ez networkön iszonyat lassú tud lenni.
Bizonyos kombinációk élesben persze tilosak, mert adatvesztést okozhatnak, de a probléma azonosításában segíthetnek.
3. Ha 2. nem hozott eredményt, akkor átírás.
* rqlite? ez elvileg replikálja a változásokat más db-kbe (nem használtam)
* más DB, sajna ez keményebb dió.
1. A fejlesztő szerint csak "nálunk" van a gond.
2. goto 1 : )
3. Nem szeretne ilyen irányban "fejleszteni"
Nekem meg nincs több ötletem.
En ilyenkor (gonoszsagbol) ki szoktam hivni az embert aki mondja, hogy akkor oldja meg o, kifizetem az utjat/idejet.
Nem ismerem a programot, de akár jogos is lehet a fejlesztő észrevétele. Ő egy egygépes megoldást csinált ahol a DB ott van ahol az alkalmazás.
Az ügyfélbázisának 99.999%-ának ez így jó. Van 1-2 problémás ügyfél, akinek ez nem felel meg. Neki meg nem éri meg átírni, tesztelni, stb.
Megoldás: vagy használja az ügyfél úgy, ahogy kellene, vagy vált másik termékre.
Hat nem tom, en sem ismerem, viszont az OP azt irta, hogy ez igy tesztelve lett a gyarto altal es ott jol megy. A fejleszto meg azzal takarozik, hogy az o rendszereben van a hiba. Akkor gondolom nem ok hackeltek ossze, hanem ez egy tamogatott feature volt.
De amugy nem eri meg valoszinuleg ezzel vacakolni van n+1 masik ilyen program.
A könyvelőiroda ezt használja 10 éve, nem akarnak váltani, mert ismerik. Viszont el tudom az érvüket fogadni, hogy egy könyvelés közben 2-5 mp-eket várni tételenként eléggé idegtépő.
De amugy a keszito ugy adta el, hogy halozatos/tobbjuzeres mukodesre kepes a szoftvere?
Akkor az ügyfél eldönti, hogy úgy használja, ahogy a fejlesztői mondja (azaz rendeltetésszerűen), vagy keres másikat.
Kapcsolókat kivezetni a fejlesztő részéről minimális erőfeszítés.
Ha erre sem hajlandó, akkor ez nem egy jóindulatú fejlesztő, hanem amolyan k-európai "örüjjé hogy döcög vazzeg és tejejjé".
Na ilyenkr ezt hagyni kell a fenébe, és más termékre váltani.
Amikor majd a személete miatt Tesco árufeltöltő lesz a fejlesztőből, akkor rájön, hogy mindig a vevőnek van igaza.
A témához kapcsolódóan:
https://www.joelonsoftware.com/2001/07/31/hard-assed-bug-fixin/
A cikk is ezt sugallja: ha egy fejlesztő azt kommunikálja feléd, hogy "nem vagy fontos nekem", akkor a felhasználó váltson.
Azt kell megérteni, hogy a szoftverfejlesztő cégek oldaláról mindig van egy erőforrás limitáció. Éppen ezért minden esetben, amikor akár hibajavítás, akár új feature fejlesztése történik, kell(ene) lennie egy felmérésnek, amely az adott fejlesztés mellé odarakja annak a költségét. Ha a várható haszon nagyobb mint a fejlesztés költsége (beleértve az új feature fejlesztése esetén a növekvő bevételeket, vagy hibajavítások esetén az ügyfél elégedettség miatti csökkenő ügyfélszám lemorzsolódást) akkor ez meg lesz csinálva. Ha nem, akkor pedig nem.
Azt kell megérteni, hogy nem minden ügyfél egyformán fontos. Az ügyfél fontossága pedig jórészt a belőle kinyerhető összeggel arányos.
Ezt egyébként több módon is meg lehet oldani: lehet például support szerződést kötni, és akkor a beadott hibajavítások előre lesznek véve. Vagy lehet egyedileg szerződni. Vagy fel lehet mondani a szerződést, és átmenni másik céghez. Vagy pedig megoldani valahogy trükközve házon belül. Ezek mind teljesen valid megoldások.
Teljesen jogos és érthető, a szoftver fejlesztőt is illik emberszámba venni.
De.
Ha ez egy több fős cég, több géppel és az elején ezt leírja egy levélben, hogy Neki ez a fejlesztés nem éri meg, akkor szerintem senki nem akasztaná fel.
A könyvelő cég is tudatában lenne, hogy ha ezt a programot akarja használni akkor mik a szükséges feltételek. Felesleges köröket verni az ügyfél és az üzemeltető agyába nem szép dolog.
Pláne azért mert egy idő után elfogy a türelem mindhárom oldalon.
Ja, ez teljesen valid, alapvetően sosem árt ha kommunikáció történik az ügyfél irányába.
Nézd, én mióta letettem a csörgőt azóta szoftvert fejlesztek, szóval ismerem ezt az oldalt, saját vállalkozásban is toltam évekig.
Sokat lehet itt rizsálni, de a lényeg: kis példányszámnál ez inkább egy szolgáltatás, ahol kinyalod a vevő fenekét, nem egy termék, amit a Tescoban gondolába ömlesztesz.
Ha a fő érvet, ami miatt téged választanánk, kiütöd, akkor meg fogsz bukni.
azt gondolom, hogy ez egy fejlettséget mutat. Van a zugfejlesztő kategória, amelyiknek van 1-2-10 ügyfele, és azoknak mindig mindent is megcsinál. Aztán van egy olyan
méret, amikor már több 100, több 1000 ügyfél van, ott ez a zugfejlesztő/garázscég mentalitás már nem működik.
Egy hálózat forgalmat esetleg még lehet nézni (wireshark) hogy hátha ott látszik valami...
"Összedugta a NAS-t a géppel egy az egyben és akkor elvileg gyors volt....)" ezen még mindig pislogok.
sőőőőt :D
SMB 3 engedélyezve van a samba-n? Ég és föld a különbség véletlen elérésben.
De megnézném w10-es "szerver"-rel is, mert a samba smb implenteciója hagy némi kivánnivalót maga után.
client max protocol = SMB3client min protocol = SMB2
server max protocol = SMB3
server min protocol = SMB2
Mivan ha iSCSI csatolod a szerverről akkor is "távoli" meghajtónak érzékeli és lassú lesz?
És akkor hogyan éri el egyszerre több kliens?
iscsi alapból lassabb mint az smb, ott még a filerendszert is babusgatja a kliens (jogosultságok felolvasása, mindenféle metaadat frissités stb-stb)
és persze nem is multiuser alapból a filerendszer.
Én a Windows offline file lehetőség felé nézegetnék. A lenti linken tárgyalják, hogyan lehet jó beállítani, "slow link mode", "automatically cache files = on". Ekkor az írás és olvasás helyileg történik és kb. 2 percenként szinkronizál.
https://superuser.com/questions/235257/local-cache-for-nas-or-network-f…
Elvileg Samba-val is megy.
https://techcommunity.microsoft.com/t5/storage-at-microsoft/using-offli…
És ez az elképzelés mennyire kompatibilis konkurensen használt adatbázis file-okkal? Mert tippre sehogy, ha egyszerre ketten dolgoznak, akkor ebből elég nagy keveredés lesz.
Én úgy értelmeztem a leírtakat, hogy már most is fájl megosztáson konkurensen használják. Illetve az ügyfél alap adatokon kívül a többi része nem konkurens hozzáférésű. De majd a rendszert jobban ismerő kérdező eldönti.
Van egy kozos.db. Ebben vannak benne a cégek alapadatai + még egyéb program információk. Ehhez minden kliens hozzányúl "folyamatosan".
CegaznositoEVSZAM.db -ben pedig a számlázási, könyvelési, stb adatok. Ezt elvileg csak az használja, aki ennek a cégnek a dolgait kezeli.
Tehát már most is osztottan használják a felhasználók? A kozos.db-t csak olvasásra nyitják meg, vagy írnak is bele?
Írnak is bele.
Az en nyakamon is maradt egy .Net hulladek. Aminel en kikotottem: virtual desktop.
Meg kene nezni, hatha elketyeg wine alatt, mert akkor a lehetosegek tarhaza nyilik ki. Csak mivel konyveloprogramoknal szokott jonni frissites, igy allando es folyamatos szivasnak nezel elebe.
Van olyan problema amit tudni kell elengedni. Szembeszellel (leszari fejleszto) nem erdemes pisalni.
Foleg, ha meg is sikerul csinalnod (most), majd egy ev mulva valamit allitgat a tisztelt fejleszto, es ujra lassu lesz, es akkor majd megy az ujjal mutogatas rad, hogy te nem ertesz hozza.
Magad alatt vagod a fat. Hazhoz mesz a lof*szert. Komolyan.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Szerintem itt a vége a történetnek:
High Concurrency
SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time. For many situations, this is not a problem. Writers queue up. Each application does its database work quickly and moves on, and no lock lasts for more than a few dozen milliseconds. But there are some applications that require more concurrency, and those applications may need to seek a different solution
https://sqlite.org/whentouse.html
Click-click módon megírt alkalmazás, csilliónyi tök felesleges írással akár a menü nyitogatásakor és már ott is vagyunk amit tüneteket leírsz.
Ezen semmilyen samba tuning nem segít. Ha normálisan lenne megírva az app (ezen a szinten nem hiszem) akkor egy adatbázis cserével megoldható lenne a történet.
Gábriel Ákos
megfelelő wireshark analízissel ezek a lock -ok szerintem láthatóak is lennének.
Gábriel Ákos
Szerintem inkább ez a vége. :)
Checklist For Choosing The Right Database Engine
Is the data separated from the application by a network? → choose client/server
Relational database engines act as bandwidth-reducing data filters. So it is best to keep the database engine and the data on the same physical device so that the high-bandwidth engine-to-disk link does not have to traverse the network, only the lower-bandwidth application-to-engine link.
But SQLite is built into the application. So if the data is on a separate device from the application, it is required that the higher bandwidth engine-to-disk link be across the network. This works, but it is suboptimal. Hence, it is usually better to select a client/server database engine when the data is on a separate device from the application.
Nota Bene: In this rule, "application" means the code that issues SQL statements. If the "application" is an application server and if the content resides on the same physical machine as the application server, then SQLite might still be appropriate even though the end user is another network hop away.
https://sqlite.org/whentouse.html
Az utolsó bekezdésben említettek alapján a kérdező által írt RDS megoldás a problémára.
igen, ez is. ide mindkettő illik, duplán vége van :)
Gábriel Ákos
+1
Még idézetek ugyaninnen:
Situations Where A Client/Server RDBMS May Work Better
Client/Server Applications
If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great.
Is the data separated from the application by a network? → choose client/server
Itt nagyjából csak az segíthet gyorsan, ha konkrét SQL utasítások helyett valamilyen ORM réteget használnak a programon belül (pl.: Entity Framework), ahol a provider elrejti a konkrét adatbázis implementációt, és nagyjából egy konfig módosítással át lehet térni egy másik, kliens/szerver alapú adatbázis-kezelőre SQLite helyett.
Utolsó mondat a nagyon kicsi adatbázistól felfelé erősen véleményes - szerintem.
Gábriel Ákos
+1, jól kell adatbáziskezelőt választani, és az nagyon nagyon sokáig elég is lesz. Ettől függetlenül persze ott a C#-ban az Entity Framework, ami elég jó ahhoz, hogy akár azt is lehetne használni.