Hi

I am running a lightly used server on XP with 2.75GB of RAM using dbsrvr 4.3 build 1.  I am getting error 11279 every couple of days and a very large page file usually around 2.5GB.  All it takes to fix the problem is to stop and start the dbsrvr service, the page file drops to around 300MB as soon as the service is stopped.  It seems to be related to TBlobField.savetofile's.  I have a Versions table that I keep the current application version in.  I launch my appication via a launcher app that first checks for the latest version and downloads it if necessary.  It then launches the real app and terminates itself.  The downloaded blobs are usually around 3MB.

Often I find that the files that are supposed to be downloaded are zero bytes in length.  I havent looked at the server code but I am presuming that the savetofile will be done in a separated thread.  Is it possible that the savetofile is being started, the code then ripples through (whilst the thread is still running) and the session is then terminated (i.e. not waiting for the thread to complete) leaving the the thread hanging?  

Any suggestions gratefully received.

Thanks

Peter

Peter,

<< I am running a lightly used server on XP with 2.75GB of RAM using dbsrvr
4.3 build 1.  I am getting error 11279 every couple of days and a very large
page file usually around 2.5GB.  All it takes to fix the problem is to stop
and start the dbsrvr service, the page file drops to around 300MB as soon as
the service is stopped.  It seems to be related to TBlobField.savetofile's.
I have a Versions table that I keep the current application version in.  I
launch my appication via a launcher app that first checks for the latest
version and downloads it if necessary.  It then launches the real app and
terminates itself.  The downloaded blobs are usually around 3MB. >>

What is the BLOB block size set to for the Versions table ?  It should be
set to around 16k-32k.

<< Often I find that the files that are supposed to be downloaded are zero
bytes in length.  I havent looked at the server code but I am presuming that
the savetofile will be done in a separated thread. >>

No, it won't use a separate thread.  What happens with SaveToFile is that
the BLOB is transferred to the client machine, and then the remote session
on the client machine saves the BLOB to the local file.

Do you have any server-side procedures defined in the DBISAM Database Server
(did you customize/recompile the server) ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim

<<What is the BLOB block size set to for the Versions table ?  It should be
set to around 16k-32k. >>

Oops, its still set to the default 512bytes, not ideal for big blobs.  I will amend it.

<<No, it won't use a separate thread.  What happens with SaveToFile is that
the BLOB is transferred to the client machine, and then the remote session
on the client machine saves the BLOB to the local file.>>

So the implication on the zero byte file size is that the client never received the transfer.  
The client that appears to be causing the worst of the problems is on a more (but not very)
remote and slower segment of the network.

<<Do you have any server-side procedures defined in the DBISAM Database Server
(did you customize/recompile the server) ?>>

No, completely its unaltered but I was thinking about including some status logging info the server so
that I can see what is triggering the problems.  Currently I am using a scheduled task to stop
the server every day in the early hours of the morning.  The page file is growing from around 300MB after
restart to 850MB after 24Hrs.  The longer its left the greater the inevitability of hitting an
"out of memory".

Thanks for the info.

Cheers

Peter

Peter,

<< So the implication on the zero byte file size is that the client never
received the transfer.  The client that appears to be causing the worst of
the problems is on a more (but not very) remote and slower segment of the
network. >>

I doubt if the network speed has anything to do with it.

Did you check to see if there are a large number of disconnected sessions on
the DBISAM Database Server when this happens ?  Something is causing runaway
memory growth, and so it should be fairly easy to track down.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Guys,

We've been hitting a similar problem on one of our servers too, and I
haven't been able to track down the cause yet.

The server is a custom built DBISAM server (using a different Engine
Signature), but everything else should be the same.

We're running with DBISAM Version 4.29 Build 2 on Windows Server 2003 R2
64bit Edition with SP2, 4GB of RAM and mountains of HDD space.

Error message logs are like:

23/12/2010 6:15:12 AM [ERROR] Engine error [Out of memory] [Client
Version: 4.29 User Name: kathy Address: 192.168.0.3 Encrypted: No
Request: REQUEST_CREATETABLE Thread: 2036 Session: 2070912304]

23/12/2010 6:11:53 AM [ERROR] Engine error [Out of memory] Additional
info [select M.ID, M.Module, M."Module Description"
into Memory\CML1
From CourseModules CM
inner join Module M on (M.ID = CM.ModuleID)
/**/ where CM.CourseID = '{343BC91D-F31D-48BE-9FC9-1D0D0A2C2A4F}'

union a [Client Version: 4.29 User Name: kathy Address: 192.168.0.3
Encrypted: No Request: REQUEST_PREPARESTMT Thread: 2036 Session: 2070912304]

and so forth.

For us, it seems to happen when a user runs a query that inserts data
into a Memory table. (However, this doesn't happen all the time. It will
run for weeks OK, and then it plays up). Once the error occurs, we need
to restart the DBISAM service on the server.

I thought about having a routine that stops and restarts the service
overnight as a work-around until I can track it down more.

No large number of disconnected sessions, and users normally close down
the client apps before they go home at night.

Cheers

Adam.

Adam,

<< For us, it seems to happen when a user runs a query that inserts data
into a Memory table. (However, this doesn't happen all the time. It will run
for weeks OK, and then it plays up). Once the error occurs, we need to
restart the DBISAM service on the server. >>

How many records are you inserting into the memory table ?  If you use
memory tables extensively, then it might be possible to exhaust/seriously
fragment the address space of the process, especially if the memory tables
are large.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> How many records are you inserting into the memory table ? If you use
> memory tables extensively, then it might be possible to exhaust/seriously
> fragment the address space of the process, especially if the memory
> tables are large.

We do use memory tables (queries) extensively, but only for report
building. Pretty much create a query that goes through a ton of data,
print the report, and then close everything down once the report has
printed.

The users can do this multiple times (for days or even weeks) and then
the error occurs.

Is it possible that a memory leak could be occurring? Or - is there
something special I should be doing to ensure that the tables are free'd
up after the report is finished?

I can understand if the problem was happening everytime the report was
run, but this happens after weeks of normal activity with no problems.

Cheers mate

Adam.

Adam,

<< Is it possible that a memory leak could be occurring? Or - is there
something special I should be doing to ensure that the tables are free'd up
after the report is finished? >>

Are you making sure to delete/drop the in-memory tables on the server after
you're done with them ?

<< I can understand if the problem was happening everytime the report was
run, but this happens after weeks of normal activity with no problems. >>

The question is if the memory usage is constantly going up over time.  If
yes, then there's either a memory leak or you're not deleting an in-memory
table that you've created.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> Are you making sure to delete/drop the in-memory tables on the server
> after you're done with them ?

Good point. I have been dropping the memory tables when the reports have
been re-run, but if a user crashed out of the application for any reason
- when their connection to the server is removed - should that delete
the memory tables then, or would they continue to remain?

> The question is if the memory usage is constantly going up over time. If
> yes, then there's either a memory leak or you're not deleting an
> in-memory table that you've created.

I'll look into this too - thanks.

Out of curiosity, is it possible to drop all memory tables from a
database connection with one command? (ie, like DROP DATABASE) which I
could preform on the appliction's exit just to make sure I've got them
all - incase any are missed through my code?

Thanks for your help Tim, and have a great new year!

Adam.

Adam,

<< Good point. I have been dropping the memory tables when the reports have
been re-run, but if a user crashed out of the application for any reason -
when their connection to the server is removed - should that delete the
memory tables then, or would they continue to remain? >>

They would continue to remain, unfortunately.  This is a necessity of
allowing multi-threaded client applications to behave the same between
local/remote sessions - in-memory tables have to be process-wide and cannot
simply be deleted when a session terminates.

<< Out of curiosity, is it possible to drop all memory tables from a
database connection with one command? (ie, like DROP DATABASE) which I
could preform on the appliction's exit just to make sure I've got them all -
incase any are missed through my code? >>

Yep:

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

It is especially useful to run this method after you have detected an
improper shutdown of your application (if possible), because it can remove
in-memory tables after the client processes/remote sessions that created
them are long gone.

--
Tim Young
Elevate Software
www.elevatesoft.com