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

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

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

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