Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 9 of 9 total |
Memory tables and memory usage (3.x) |
Tue, Nov 25 2008 7:25 AM | Permanent Link |
durumdara | Hi!
I wanna ask something about memory tables, because I don't understand them fully. I created a test application to modelling. The application, that do this: procedure TForm1.BitBtn1Click(Sender: TObject); begin OpenDB; with qm do begin Close; SQL.Text := 'select * into memory XAXX from work; select * from memory XAXX'; Open; end; end; This "work" table have 3 files, IDX, DAT, BLB, and total size (with all) is: 10,8 MB (4,1 + 5,1 + 1,4). When I opened this application, the server created three files in the server, but they have only 1k - 50k size. The memory usage of the dbserver growed with 10MB. Because of fake file size, I checked the disk usage with "dir", and I saw that different between prior (non connected), a connected state is 438K. Hmmm... It seems to be the server held the data in it's memory area (RAM, VM), not in the filesystem! After that I started this app, and I closed it again, and again. Everytime I saw the temp table creation (1k-50k), and the disk usage growed, and after I closed the app, it normalized to prior state. But the server's memory usage is not! It is growing with 10 MB for each app running, and it is not decreased! I started this app 8 times, and I got 80 MB memory usage by the server. So I wanna ask: when this memory will released by server? Why it held? Why not the filesystem used? Or it will flushed to files later? Please help me to clear the definition of the memory tables, and to I can get solution our OM error (possible caused by memory tables). Thanks for it: dd |
Tue, Nov 25 2008 8:27 AM | Permanent Link |
"Eduardo [HPro]" | Durumdara
> SQL.Text := 'select * into memory XAXX from work; select * from memory > XAXX'; > Open; > end; > end; > > This "work" table have 3 files, IDX, DAT, BLB, and total size (with all) > is: 10,8 MB (4,1 > + 5,1 + 1,4). > > When I opened this application, the server created three files in the > server, but they > have only 1k - 50k size. > The memory usage of the dbserver growed with 10MB. > Because of fake file size, I checked the disk usage with "dir", and I saw > that different > between prior (non connected), a connected state is 438K. > > Hmmm... It seems to be the server held the data in it's memory area (RAM, > VM), not in the > filesystem! Yes, as you said before *memory* tables. Memory tables are held in server memory (RAM) > After that I started this app, and I closed it again, and again. > Everytime I saw the temp table creation (1k-50k), and the disk usage > growed, and after I > closed the app, it normalized to prior state. It is correct too. You create the memory table and then you have to destroy it. > But the server's memory usage is not! It is growing with 10 MB for each > app running, and > it is not decreased! Just add the following code in the form destroy of you application. Sql.Text := 'drop table if exists memory\xaxx'; ExecSql; Eduardo |
Tue, Nov 25 2008 9:10 AM | Permanent Link |
durumdara | "Eduardo [HPro]" <contato@hpro.com.br> wrote:
Durumdara >> Hmmm... It seems to be the server held the data in it's memory area (RAM, >> VM), not in the >> filesystem! >Yes, as you said before *memory* tables. Memory tables are held in server >memory (RAM) It is ok, but sometimes they are flushed to disk. I saw many times, but I don't understand why sometimes yes, and why sometimes not??!! >> But the server's memory usage is not! It is growing with 10 MB for each >> app running, and >> it is not decreased! >Just add the following code in the form destroy of you application. >Sql.Text := 'drop table if exists memory\xaxx'; >ExecSql; OK, I know it, but a.) This is not my code, and I must follow, and correct all usage of these tables, one by one (60-100?). Very hard area for me. b.) I don't understand, that the memory usage of the dbserver why not decreased. For example: in 12:00 I started 10 pieces of the memory eater. Each of them eating 10 MB of server memory with "select * from XAXX". The temp. files are closed, and it is 15:00, but the server memory usage constantly 100 MB. Dead session count = 0; Intervals = 300; DS Cleanup: 30 sec. So what is it that held the memory? And when it will released? Thanks for your help: dd |
Tue, Nov 25 2008 10:00 AM | Permanent Link |
durumdara | Hi!
Next test: I can realize the Out of Memory error, when I used a code to "select into memory X", and don't delete the results. Interesting, that memory usage does not decreased, the dbserver held all memory that it can, and never release the older client's non-deleted memory tables... Hmmm... I thought before that the server reuse the memory of the disconnected sessions, but it seems that isn't do it. Why??? Thanks: dd |
Tue, Nov 25 2008 6:35 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << Next test: I can realize the Out of Memory error, when I used a code to "select into memory X", and don't delete the results. Interesting, that memory usage does not decreased, the dbserver held all memory that it can, and never release the older client's non-deleted memory tables... >> See my other message regarding this method: http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=RemoveAllRemoteMemoryTables Just add this method call to your remote session in the client application before you close the application, and that should take care of the problem. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Nov 26 2008 10:39 AM | Permanent Link |
"Robert" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:26B9C87A-0DFB-4D23-92E4-2EFA4F638FA8@news.elevatesoft.com... > > See my other message regarding this method: > > http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=RemoveAllRemoteMemoryTables > > Just add this method call to your remote session in the client application > before you close the application, and that should take care of the > problem. > This applies also to V4? Robert |
Sat, Nov 29 2008 3:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< This applies also to V4? >> Shoot, I forgot that he was using 3.x. This actually *only* applies to 4.x, and not 3.x. He's going to have to make sure to drop all memory tables manually after he is done using them. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Dec 1 2008 6:45 AM | Permanent Link |
durumdara | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
>Robert, << This applies also to V4? >> >Shoot, I forgot that he was using 3.x. This actually *only* applies to 4.x, >and not 3.x. He's going to have to make sure to drop all memory tables >manually after he is done using them. Thanks. I found this way, but I inspected this problematic corp, and I saw that they are not close the application until 16.00 (the ending of the work). So all things are existing continously. This is the time to I find some way to recompile this version of the DBISAM server. I wanna ask that IF WE DON'T BOUGHT THE SOURCE FOR THIS VERSION FORMERLY, CAN WE BUY IT NOW? The 4.x version is problematic because many thing changed, and we need to recode all specific things in all source. This is hard and that can be the source of many new bugs. So I wanna ask that: a.) Can we buy 3.x sources from you? b.) Can we compile with Delphi 6.0 Prof/XP? c.) Can we build it with FASTMM (version problems?)? Thanks for your help: dd |
Mon, Dec 1 2008 3:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << a.) Can we buy 3.x sources from you? >> Contact Sales at sales@elevatesoft.com and they will help you with this. << b.) Can we compile with Delphi 6.0 Prof/XP? >> Yes. << c.) Can we build it with FASTMM (version problems?)? >> Yes. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, April 26, 2024 at 06:09 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |