Tim

1) Is this right ?
I have one application with around 150 tables and around 50 users.
150 tables x 150 Kb per table x 50 users = around 1Gb RAM.

2) The company stop working 7:00 PM and after three or four hour the server
(Win2003) shows DBSRVR using 1.2GB RAM (task manager).
Even without any user logged on, the memory usage should not be much lower ?

3) I am using FASTMM and it shows me no memory leak. What could I do to find
if there is something with memory leak in my application ?

Thanks in advance.

Eduardo

Eduardo,

<< 1) Is this right ?
I have one application with around 150 tables and around 50 users. 150
tables x 150 Kb per table x 50 users = around 1Gb RAM. >>

Only if:

a) You are talking about 50 *concurrent* users, and
b) They always have all 150 tables open in each session

<< 2) The company stop working 7:00 PM and after three or four hour the
server (Win2003) shows DBSRVR using 1.2GB RAM (task manager). Even without
any user logged on, the memory usage should not be much lower ? >>

Where are you seeing this, in the task manager ?  Is it actual memory usage
or the VM size ?  Finally, are you running the server as an application or a
service, and with or without the user interface ?

<< 3) I am using FASTMM and it shows me no memory leak. What could I do to
find if there is something with memory leak in my application ? >>

FastMM will tell you if there's a leak when you shut down the server, if
you're using the default FastMM settings.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

> a) You are talking about 50 *concurrent* users, and
> b) They always have all 150 tables open in each session
Yes, that is the case.

> Where are you seeing this, in the task manager ?  Is it actual memory
> usage or the VM size ?  Finally, are you running the server as an
> application or a service, and with or without the user interface ?
I am using Task Manager. Memory usage. I am running server as a service
without user interface.

> FastMM will tell you if there's a leak when you shut down the server, if
> you're using the default FastMM settings.
Ok, I know how to do it and I will do it asap.

Eduardo

Eduardo,

<< I am using Task Manager. Memory usage. I am running server as a service
without user interface. >>

That should be okay.

Are you using pinging in the remote sessions ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Yes, I am using it. I can disable it for a test.

Eduardo

Eduardo,

<< Yes, I am using it. I can disable it for a test. >>

No, it shouldn't be a problem.  The reason I was asking was to see if there
was any possibility that any dead sessions were hanging around.  With
pinging, it is impossible unless your dead session expiration setting is
extremely high.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

When you asked me about remote ping yesterday, I remove it and update the
customer site. But investigating more and more I have noticed in this
application has *A LOT* of situation with "select ... into memory\MyTable"
without drop them after use.

If I am understanding the way of memory tables work, the server DBSRVR use
the name of workstation + process ID (at client side) followed by the name
of the memory table.
Example: EDUARDO2134MyTable.

But if I quit my application (without dropping the memory tables) and enter
again, the application receives another PID and therefore the situation
would be worst and worst because another memory table will be created
(EDUARDO3412MyTable) and the old one is still there. It will happen with the
other users too and the problem will increase during the day. In this
customer they don´t turn off the server every day, then DBSRVR hold memory
tables until "Out of Memory".

I am changing the application to fix this and I will let you know if the
problem has gone or not.

Thanks for your tips.

Eduardo

Eduardo,

<< If I am understanding the way of memory tables work, the server DBSRVR
use the name of workstation + process ID (at client side) followed by the
name of the memory table.
Example: EDUARDO2134MyTable. >>

You are correct.

<< But if I quit my application (without dropping the memory tables) and
enter again, the application receives another PID and therefore the
situation would be worst and worst because another memory table will be
created (EDUARDO3412MyTable) and the old one is still there. It will happen
with the other users too and the problem will increase during the day. In
this customer they don´t turn off the server every day, then DBSRVR hold
memory tables until "Out of Memory". >>

Yes, that is correct.

<< I am changing the application to fix this and I will let you know if the
problem has gone or not. >>

Just so you know, this method can also help with this:

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

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Since I don´t use TDBISamQuery directly and instead of I use an inherited
component, I have created a mechanism to deal with memory tables and when I
close or destroy the query, it internally drops memory tables from server
memory. It was so easy to create this (yesterday), and today I see the
results. The problem is gone.

I have already seen the RemoveAllRemoteMemoryTables but my component right
now deal with this "little" problem.

BTW, thanks for your help.

Eduardo

Eduardo,

<< I have already seen the RemoveAllRemoteMemoryTables but my component
right now deal with this "little" problem. >>

I'm glad that you resolved the issue.

--
Tim Young
Elevate Software
www.elevatesoft.com