![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 4 of 4 total |
![]() |
Tue, Oct 20 2009 2:50 AM | Permanent Link |
Saajid | Hi,
We have deployed DBISAM database for an installation where the number of concurrent users is in range of 100 to 150 users. We are experiencing some problems in stability of the application like (1) At times, records are not getting updated into database. (2) Database Server memory utilization goes very high and reaches a stage where the application stops responding( because DBISAM server has reached the max mem) (3) Disconnection from DBISAM service. Are there any particular issues that may be generated from DBISAM when the number of concurrent users are increased above 100 or so? Please advice. Regards Ahamed |
Tue, Oct 20 2009 6:10 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Saajid,
<< We have deployed DBISAM database for an installation where the number of concurrent users is in range of 100 to 150 users. We are experiencing some problems in stability of the application like (1) At times, records are not getting updated into database. (2) Database Server memory utilization goes very high and reaches a stage where the application stops responding( because DBISAM server has reached the max mem) (3) Disconnection from DBISAM service. Are there any particular issues that may be generated from DBISAM when the number of concurrent users are increased above 100 or so? >> Firstly, what version of DBISAM are you using ? Also, how much memory does the server machine have ? Lastly, are you seeing any weird errors in the server log (dbsrvr.log), which is viewable from the Server Administration Utility ? The only major issue that you're run into with that many users is possibly running out of memory on the server machine. When you design such a system, you cannot design it like you would an application that will be opening and caching tables on the client machines only. You have to be judicious about how much memory each session uses by keeping open tables to a minimum. For example, opening all 200 tables in a single data module at application startup is not recommended when you're designing for above 100 users, and it's probably a bad idea for anything above 50 users. I'm assuming *concurrent* users here, by the way. It's very simple to do the math. Say that each session opens a lot of tables, and the total consumption per session on the database server is 16MB. If you have 100 concurrent users, then the sessions alone will consume close to 1.7GB of memory, and will most likely never get that high due to some fragmentation of the virtual address space for the database server process. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Oct 20 2009 9:01 AM | Permanent Link |
Saajid | Hi Tim,
We are using is version 3.24 Last time when we checked the log, there was no weird messages , except that we saw many connection and disconnections. The log file can be viewed from the below location. http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=13&msg=1719&keywords=saajid*#msg1719 Regards Saajid "Tim Young [Elevate Software]" wrote: Saajid, << We have deployed DBISAM database for an installation where the number of concurrent users is in range of 100 to 150 users. We are experiencing some problems in stability of the application like (1) At times, records are not getting updated into database. (2) Database Server memory utilization goes very high and reaches a stage where the application stops responding( because DBISAM server has reached the max mem) (3) Disconnection from DBISAM service. Are there any particular issues that may be generated from DBISAM when the number of concurrent users are increased above 100 or so? >> Firstly, what version of DBISAM are you using ? Also, how much memory does the server machine have ? Lastly, are you seeing any weird errors in the server log (dbsrvr.log), which is viewable from the Server Administration Utility ? The only major issue that you're run into with that many users is possibly running out of memory on the server machine. When you design such a system, you cannot design it like you would an application that will be opening and caching tables on the client machines only. You have to be judicious about how much memory each session uses by keeping open tables to a minimum. For example, opening all 200 tables in a single data module at application startup is not recommended when you're designing for above 100 users, and it's probably a bad idea for anything above 50 users. I'm assuming *concurrent* users here, by the way. It's very simple to do the math. Say that each session opens a lot of tables, and the total consumption per session on the database server is 16MB. If you have 100 concurrent users, then the sessions alone will consume close to 1.7GB of memory, and will most likely never get that high due to some fragmentation of the virtual address space for the database server process. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Oct 20 2009 10:45 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Saajid,
<< We are using is version 3.24. Last time when we checked the log, there was no weird messages , except that we saw many connection and disconnections. >> Send me a private email (timyoung@elevatesoft.com) and I will send you a debug version of 3.30 that should give us an idea of where the problem is with the "invalid pointer operation" error during session removal. It looks like that is causing sessions to hang around until the memory usage is extremely high. In addition, it would be highly beneficial for you to use FastMM4 as the memory manager, which is what this debug server will use. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |