Our customers updated from 8.1 to 8.6.
Now they have to reboot their servers or restart the server-engines
after some days, because the applications can't connect to the
database.
It seems ntdbsmgr.exe occupies more and more memory until the
described problem appears. Anyone who has a solution or experienced
the same?

I experienced the same in 8.0 and someone told me to install SP1 to resolve
the problem, but I don't know if I install now it after I read your message.
My problem of the memory usage was that in PVSW 8 my files grow hugh (6 Gb)
which they didn't in PVSW 7.

Barry

"Peter K" <klauss (AT) atelion (DOT) de> wrote

Pervasive database manager will only use as much memory as you tell it
to use. Default installation with early versions of Pervasive.SQL V8
was somewhat abusive by allowing the Engine to use up to 90% of
internal memory. The problem you describe is most likely the result of
this setting.

Becasue Pervasive.SQL V8.6 defaults to 60%, running a fresh install
with this version should not get you that kind of problems unless of
course the host is also running several other memory consuming
services. On average this means you're likely to encounter these
problems with most SMB who are running a single (Windows based)
server.

Gordon


On 3 Jan 2005 02:00:14 -0800, klauss (AT) atelion (DOT) de (Peter K) wrote:


Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/

There are two things you may want to try.
The first is a setting that tells the engine how much free space can
be in a data file. The setting is in the Pervasive Control Center
under the Server settings in the Performance group. The setting is
"File Growth Factor". By default it is 15%. There was also a defect
fixed in SP1, from http://www.pervasive.com/downloads/historyV8_Nt.txt

43818 Alleviated a problem where a file using the 8.x format could
grow too large when inserting a number of records consecutively. Under
certain conditions when there is heavy concurrency with multiple
clients updating the same page in the file, this issue could also
cause a status 54 or 2 to be returned.

The other option would be to go back to the 7.x file format which
would disable the Turbo Write Accelererator feature.

Leonard

On Mon, 03 Jan 2005 15:03:51 GMT, "Barry van den Reek"
<barry (AT) liemar (DOT) nl> wrote:

The setting you mention "Max MicroKernel Memory Usage" can be set all
the way down to 0. That disables the dynamic cache sizing in the
database engine. The database engine will still use whatever amount
of memory is set for "Cache Allocation Size" for caching as well as
some additional memory for other data structures and the executables
themselves.

You did not mention which OS you are running on but for Windows the
Windows task manager is your friend for monitoring memory usage. Keep
in mind that no matter how much memory is installed in the computer a
single process can only use 2GB of it*. *Except for those versions of
the OS that allow the /3GB boot switch to be set and the /3GB boot
switch is set.

Leonard

On Mon, 03 Jan 2005 17:10:52 +0100, Gordon
<grafzerk (AT) bigfoot (DOT) no.spam.please.com> wrote:

On Fri, 07 Jan 2005 08:02:17 GMT, Leonard <lharvey (AT) austin (DOT) rr.com>
wrote:

Correct! I didn't. I was replying to the subject "Win 2003 Server
hangs after some time".

Also, apart from this particular problem L2 cache rarely poses a
problem. Most memory related problems are the result of L1 cache
conflicting with other applications (such as store.exe). And SMB in
this context does not refer to Samba....

Kind of thoughtless of me to use this acronym, so to Peter and Barry:
in both German and Dutch it translates as MKB.


Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/