TIBDataSet Memory Problem

Zdravo,

imam problem s TIBDataSet komponentom, kad se radi o nekoliko miliona recorda.

Komponenten:
TIBDatabase -> baza firebird
TIBTransaction
TDataSource
TIBDataSet
TDBGrid

problem se desava kad korisnik povuce scroll prema dole tj. predje na zadnji record
u tom momentu pocinje da raste koristenje memorije (task-manager)
i nekad kad dodje do 1GB iskoci exception

da li postoji neko rjesenje za ovaj problem?
svaka ideja ili savjet je dobrodosla.
hvala.

Problem je što TIBDataSet omogućava dvosmerni (kretanje napred i nazad) rad sa datasetom tako da mora keširati sve u memoriji, ako ti memorija dolazi do 1GB onda ili postoji neki bug u IBXu ili imaš ogromnu tabelu. Ako je u pitanju ogromna tabela onda tu nema mnogo pomoći, prelazak i na drugu biblioteku neće mnogo promeniti jer u osnovi svaka mora da kešira podatke, ima efikasnijih pa će limit biti veći, pokušaj da filtriraš podatke prema nekom kriterijumu, korisniku sigurno ništa ne znači da vidi milion slogova.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html

Hvala na odgovoru.
Znam da TIBDataSet koristi dvosmjerni rad, zato i mogu samu tu komponentu koristiti s DBGridom.
Radi se o podacima koji su u stvari protokoli (LOGs) s klijent racunara.
Tako da se u centralnoj bazi nalaze milioni recorda.

Mi imamo filter za sva polja, ali kad korisnik hoce da provjerava sta se radilo na pojedinim klient racunarima onda vecina korisnika izabere nekoliko klienata i nekoliko mjeseci itd.
Tako da query ima recimo 1mio podataka.
To ide sve ali ako u tom momentu klikom na scroll i povuce dole, tj. desi se Query.LAST onda pocinje MoveBy :-) i s tim i upotreba RAM-a.

Znao sam da vecina komponenti funkciona isto tako, cak sam danas testirao FireDAC iz Delphi XE7 i isti problem :-)

Jedno drugo pitanje ali vezano za ovo.
Da li je moguce da se negdje definira koliko memorije moze da koristi program?
Serveri gdje se ovo sve izvrsava imaju dovoljno RAMa tako da kad bi mogao reci da program recimo koristi nekoliko GB memorije onda bi rjedje imao taj problem.

32bitna aplikacija? Oni po defultu imaju ogranicenje od 2GB memorije, ima neki switch da se to poveca na 3GB a najbolje je da kompajliraš kao 64bitni i onda nema ograničenja. E sad to je što se tiče samog procesa i Windowsa ali ne znam za same komponente, možda one imaju neko drugo ograničenje, to se mora probati.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html

Zanimljiv problem, bogami .

$31, otvori unit koji sadrzi TIBDataSet klasu ('Find declaration' - desni click). Potrazi u nekoj ancestor klasi (ovo sam video u verziji za D7, doduse) private member FCacheSize; ako je tip Integer - nema pomoci, svejedno da l je 32/64-bitni kompajler.

I malo sam iznenadjen da (konkretno XE2) u novijim verzijama Delphi-ja nisu uvedeni 'prosireni' integer tipovi; kako vidim, LongInt je i dalje Integer, a novih tipova nema. Int64 je po definiciji record od dva integer-a - sto mene malo frustrira: ima li Delphi PRAVI 64-bit tip integera (podrsku kompajlera za isti)?

Pozz

P.S. Moram da se ispravim u vezi Int64. Pogledao unit System, sve assembler rutine vezano za pomenuti tip imaju switch CPUX64/CPUX86, znaci kompajler PODRZAVA 64-bitne registre .

> otvori unit koji sadrzi TIBDataSet klasu ('Find declaration' - desni click). Potrazi u nekoj ancestor klasi (ovo sam video u
> verziji za D7, doduse) private member FCacheSize; ako je tip Integer - nema pomoci, svejedno da l je 32/64-bitni kompajler.

Mozda moze da se zameni direktno u unitu pa da radi ili da se proba neki drugi library, mora da postoji neki koji je 64bit ready, mozda FireDac?

> I malo sam iznenadjen da (konkretno XE2) u novijim verzijama Delphi-ja nisu uvedeni 'prosireni' integer tipovi; kako vidim, LongInt je
> i dalje Integer, a novih tipova nema.

Ima NativeInt, Integer je ostao 32bitni jer je Windows tako uradjen pa su oni samo zadrzali kompatibilnost sa MSom.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html

ipak smo se na kraju odlucili na jednu jednostavniju varijantu :-)

svi upiti koji se koriste sa dbgrid imaju ogranicenje na 100.000 recorda



sa ovim ako korisnik i scrolla, upotreba RAMa naraste do max 250MB (u mom slucaju)

s obzirom da se dbgrid moze raznim kriterijima filtrirati ovih 100.000 je i vise nego dovoljno da se nadju zeljeni podaci

Pa napravi opciono da korisnik ukoliko ne nade zeljene podatke u prvih 100000 sloga da se ucitaju narednih 100000 i tako do kraja baze.

Opet ja i opet isti problem :-(

Ovo gore s DBGrid-om je s ovim rjesenjem od 100.000 prihvatljivo i radi kako treba.

E sad na drugoj formi slican problem. O cemu se radi?

Na formi se nalaze razlicita polja za unos podataka o kupcu (TDBEdit, TDBComboBox, TDBNavigator).
U tabeli se nalazi preko 100.000 podataka i kad korisnik klikne u navigatoru na zadnji bbLast onda se desi upravo ono sto se desavala i sa DBGrid-om tj. IBDataSet ucitava svaki record do zadnjeg i samim tim pocinje da raste koristenje RAM-a.
I negdje oko 700MB na mom PC-u izleti exception da nema dovoljno memorije.

Nesto sam razmisljao da napravim novu CustomIBDataSet komponentu i da ovaj dio gdje se ucitava svaki record nekako drugacije uradim???!!!


Ima li neko kakvu ideju kako ovo rjesiti ili drugacije implementirati?

Bubam bezveze, ali možda da napraviš novi upit i promijeniš order kada kliknu na bblast. Ali to vjerojatno ne budeš mogao sa DBNavigatorom, morao bi napraviti svoj.
U biti cijeli problem leži u tome da nikada ne učitavaš sve recorde nego samo onoliko koliko ti treba.

Potpis

F

Danas sam sasvim slucajno dosao do jedne interesantne informacije.
Za brzi pregled podataka u bazi koristimo IBOConsole, dosta stara aplikacija ali radi jos uvijek dobro.
I kad sam obe baze s kojima sam imao problem testirao s ovim programom nisam dobio problem s memorijom :-)
I citajuci na net-u kako je implementiran IBOConsole vidim da pise da je programer koristio IBObjects.
Znaci postoji razlika u implementaciji komponenti tj. neke koriste manje ili vise memorije.

E sad nije bas tako lako da se kompletan source-code prebaci na neke druge komponente ali eto ipak ima drugacijih (boljih/losijih) rjesenja.

Probaj da povecas memoriju koju ti koristi aplikacija.
U delu projecet view source (glavni unit) unesi instrukcije kompajleru

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}
{$MAXSTACKSIZE 1073741824}

Ovo ce da ti poveca dostupnu memoriju u aplikaciji na max.
Ako ovo one bude dovoljno nacicemo neko drugo resenje.

IBObjects je kvalitetniji od IBXa ali se posebno kupuje, znam da je prelazak sa BDEa lak na IBO ali ne znam za IBX, verujem da nije preveliki problem, uzmi trial pa probaj. Pravljenje custom varijante IBXa će verovatno biti komplikovano, pogledaj i druge alternative, FireDac (dolazi uz novije Delphije) i UIB koji je besplatan i najbrži za jednosmerni pristup FB ali ne znam kakav je u dvosmernom datasetu.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html

Hvala na informacijama i pomoci.
Jucer sam testirao nekoliko komponenti.
UIB i ZEOS isto koriste TDataSet iz Data.DB tako da su tu neke druge stvari implementirali drugacije ali ne i ovo gdje ja imam problem.
FireDAC sam isto tako testirao prije nekoliko dana, koliko sam ja mogao da primjetim nesto manje memorije koristi ali isto tako pri velikom broju recorda postoji problem.

Skinuo sam Trial IBObjects i testirao na tabelama preko milion slogova i radi bez exception-a, potrosnja memorije je nekoliko stotina MB, tako da ove komponente definitivno imaju najbolje implentiran dio s koristenjem memorije.
Jedino je problem s ovom komponentom sto se mora i Database i Grid koristiti, znaci ne moze standardni DBGrid itd. sto znaci vise posla prilikom implemetacije :-)

Nesto sam gledao kod klase TIBDataSet (i ancestora), vezano za 64-bitni rad sa memorijom.
Evo nekoliko opaski:

1) FCacheSize (i slicne varijable), treba promeniti tip na NativeInt (koji je genericki tip, to jest zavisi od sistema).
2) Za alociranje memorije se poziva funkcija IBAlloc(). Pogledao sam, koriste se procedure ReallocMem() ili GetMem(); treba zameniti funkcijama ReallocMemory() i GetMemory(); ne zaboraviti takodje i FreeMemory(). Move() vec radi sa NativeInt parametrima.
3) E sad, pointer. Nasao u helpu-u da je on takodje sam po sebi genericki tip, odnosno na 64-bitnom sistemu sa 64-bitnom verzijom kompajlera, pointer ce biti takodje 64-bitan. Nemam 64-bitni Delphi instaliran trenutno da probam sizeof(pointer).

To su neke smernice kojih bi se ja drzao ako bih krenuo da menjam/prilagodjavam kod pomenute klase za 64-bitnu memoriju. Istina je da tu sigurno ima jos kvaka za peglanje; medjutim vidim da je NativeInt vec koriscen/naveden na par mesta u tom unit-u.
Sto se tice podrske za TDataSet (override-ovane metode), jedine koje imaju parametre (ili vracaju result) tipa Integer su GetRecordNo i GetRecordCount. Postoji i ovo procedure ClearCalcFields(Buffer: NativeInt);overload; override;, sto me pogotovo drzi u uverenju da nije nemoguc zadatak.
Puno srece!


Pozz

Interesantna stvar, pojavio se i kod mene u firmi slican problem; velika kolicina podataka pa na grid.
Dakle, kolega je probao FireDAC iz 64-bitnog XE-a i bogami, radi ko grom. Bez problema je povukao par miliona record-a, zauzece memorije preko 7 GB. E sad, kad je ubijao aplikaciju to potraje, jer oslobadja virtuelnu memoriju (citaj: zapise na disku); ali cim se dodje do zapisa na fizickom RAM-u, shutdown aplikacije je trenutan.

Pozz

> Interesantna stvar, pojavio se i kod mene u firmi slican problem; velika kolicina podataka pa na grid.
> Dakle, kolega je probao FireDAC iz 64-bitnog XE-a i bogami, radi ko grom. Bez problema je povukao par miliona
> record-a, zauzece memorije preko 7 GB. E sad, kad je ubijao aplikaciju to potraje, jer oslobadja virtuelnu
> memoriju (citaj: zapise na disku); ali cim se dodje do zapisa na fizickom RAM-u, shutdown aplikacije je trenutan.

7GB? Pretpostavljam da sama tabela nije toliko vec da FireDac neefikasno cuva podatke u memoriji.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html