Hi!

I wanna ask you that what is the correct definition of the:
"Total Sessions"
and
"Total Connected Sessions".

As I know the "Total Sessions" are all sessions on the servers. So all objects (Connected,
No Connected, Dead).
And Total Connected that sessions are still alive.

Because in one place we saw that "Total Connected Sessions" is bigger than "Total
Sessions" (with 1, 2, or 3 sessions).

In this place we have many problems because of daily Out Of Memory errors, and other
abnormality happening in the time interval 12:00-15:00.

Every of these "crashes" are beginning with an access violation and later we got OM (mani
Padme Hum).

The system admin reports us that before crashes the memory usage of the process is 2,7 GB
in the all time.
In the beginning of the day the memory usage is low, later it is growing, before the crash
it is growing logarithmically.

The known server params: Total Conn: 300, Dead Session Exp 1800 sec. Conn. timeout is 300
or 600. Dead S. Max: 64.

The total sessions are commonly 50-60. The reported memory usage is different from real
usage, with 100-N? MB.
The total db size is 2-4 GB. The users used more programs. Every program uses 30-60 tables.

I waiting to other params from the sysadmin now.

Thanks for your help:
 dd

<< I wanna ask you that what is the correct definition of the:
"Total Sessions"
and
"Total Connected Sessions".

As I know the "Total Sessions" are all sessions on the servers. So all
objects (Connected, No Connected, Dead).
And Total Connected that sessions are still alive. >>

Correct.

<< Because in one place we saw that "Total Connected Sessions" is bigger
than "Total Sessions" (with 1, 2, or 3 sessions). >>

What version are you using ?

<< In this place we have many problems because of daily Out Of Memory
errors, and other abnormality happening in the time interval 12:00-15:00.

Every of these "crashes" are beginning with an access violation and later
we got OM (mani Padme Hum).

The system admin reports us that before crashes the memory usage of the
process is 2,7 GB in the all time. In the beginning of the day the memory
usage is low, later it is growing, before the crash it is growing
logarithmically. >>

Are you using the latest DBISAM 4.x with the FastMM4 memory manager, or the
older versions of DBISAM 4.x with the DBISAM memory manager ?

BTW, you should normally report these types of issues via the support email
address (support@elevatesoft.com).  I really can't analyse these types of
issues via the newsgroups very well.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:


<< Because in one place we saw that "Total Connected Sessions" is bigger
than "Total Sessions" (with 1, 2, or 3 sessions). >>
>What version are you using ?

Exe version 3.24.1.1.

>Are you using the latest DBISAM 4.x with the FastMM4 memory manager, or the
>older versions of DBISAM 4.x with the DBISAM memory manager ?

Older version with Default manager.

>BTW, you should normally report these types of issues via the support email
>address (support@elevatesoft.com).  I really can't analyse these types of
>issues via the newsgroups very well.

Ok, thanks for your help:
 dd

<< Exe version 3.24.1.1. >>

That's going to be a bit of an issue.  We aren't issuing any more updates
for 3.x (and haven't been for several years now).

You can try re-compiling the 3.x database server using something like
FastMM4 to see if that helps.  However, you'll need to have the source code
version of DBISAM 3.x to do so.  It sounds like you're hitting a memory
ceiling in terms of the process address space, and FastMM4 may improve on
the memory allocation significantly.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi!

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

<< Exe version 3.24.1.1. >>

>That's going to be a bit of an issue.  We aren't issuing any more updates
>for 3.x (and haven't been for several years now).
>You can try re-compiling the 3.x database server using something like
>FastMM4 to see if that helps.  However, you'll need to have the source code
>version of DBISAM 3.x to do so.  It sounds like you're hitting a memory
>ceiling in terms of the process address space, and FastMM4 may improve on
>the memory allocation significantly.

Yes, I thinking in same source of the problem.
I wanna ask that in 3.x version can I get all memory table names in the server?
Because I wanna know that which memory tables exists in the server, and I wanna get some
onfly statistics about them.

For example:
GetMemoryTableNames(sl);
for i := 0 to sl.Count - 1 do begin
 q.SQL.Text := 'select * from ' + sl[i] + '  top 1';
 q.Open;
 RSize := q.RecordSize;
 q.SQL.Text := 'select count(*) from ' + sl[i];
 RCount  := q.Fields[0].AsInteger;
 FullSize := RSize * RCount;
end;

Possible the programs leaving some tables in opened state, and these tables make this
"leak" (and this is not a server problem (bug)).

Or how to I get any informations about the server from 3.x components, and/or from the
filesystem (for example where the memtables stored).

Thanks for your help:
 dd

<< I wanna ask that in 3.x version can I get all memory table names in the
server? >>

Unfortunately, no.

<< Possible the programs leaving some tables in opened state, and these
tables make this "leak" (and this is not a server problem (bug)). >>

If that's the case, then you should investigate using this method:

http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=RemoveAllRemoteMemoryTables

--
Tim Young
Elevate Software
www.elevatesoft.com