We use a pervasive database (Version 8.10) on a WIN 2003 Server and we
recently had the problem that the pervasive process ntdbsmgr.exe
floods our memory. Due to this, applications which are working based
on this database have no more access to it . After a restart of the
database everything seems to work well again.

Any idea what the reason for this could be? Clien Caching is turned
off and we assigned 800 MB of the 1 GB memory to the pervasives in the
control center. The MicroKernel Memory Usage is at 60%.


greets and thanks

In most cases there should be no need to assign that much cache for
Pervasive.SQL V8. You should note that this primary (L1) cache has to
be consecutive memory, which you will probably not be able to allocate
on a 1Gb machine. I'm not sure how the engine will react to being told
to allocate 800Mb and at the same time being told to allocate a max of
640Mb (60%).

You should try a lower setting for (L1) cache, say 256Mb, and let the
Pervasive engine manage the remainder.

Gordon

On 10 May 2004 03:56:39 -0700, o.senzig (AT) pvs-limburg (DOT) de (OSenzig)
wrote:


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

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

Actually with Pervasive.SQL V8 the requirement for contiguous memory
went away. This has started letting the database engine run into the
2GB OS memory limit, but from the description below sounds ok.

Tuning really is a black art. Sometimes it is better to allocate say
800MB for CacheSize and set Max MicroKernel Memory = 0
sometimes it is not. Other times the defaults are faster which on
that system would be about 200MB L1, 80% L2 (90 is usually a little
too high), and check that System Cache is back to off.

Rebuilding files to at least 6.x format is being smart.
Rebuilding files to have 4K data pages can help performance
significantly.
Rebuilding the files to the 8.x file format can help performance too.

Leonard

On Mon, 10 May 2004 14:31:37 +0200, Gordon
<grafzerk (AT) bigfoot (DOT) no.spam.please.com> wrote:

Sorry Leonard, but that's incorrect: L1 cache still has to be
contiguous. It's L2 cache that may be fragmented. The big difference
between the two is that L1 cache also acts as workspace and L2 cache
is plainly swap space. The L2 cache is designed to take advantage of
OS resources without putting a strain on the entire system. Setting a
huge L1 cache may give you some microseconds advantage but may have
serious effects on other processes and eventually the whole system.

L1 cache has a minimum size requirement based on number of consecutive
users, open files and their pagesizes. Other than that you can set it
to any amount you see fit but you should realize there's absolutely no
gain when the OS starts swapping your L1 cache to disk.

Gordon

On Mon, 10 May 2004 13:26:45 GMT, Leonard <lharvey (AT) austin (DOT) rr.com>
wrote:


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

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

I am sure that L1 no longer needs to be contiguous with V8.
Servers that could never get more than 500 MB contiguous with 2000i
are quite happy at 1GB+ with V8. Also if you look at the task
manager, the memory grows up to the L1 setting instead of jumping
there as it did previously. This does of course assume that there is
actually that much memory available.
Also straight from the What's New manual:
http://www.pervasive.com/library/doc...perfmkde3.html
"The memory cache referred to in this document as "Level 1 (L1)" cache
is exactly the same cache that Pervasive.SQL has always offered,
except that in Pervasive.SQL V8 it no longer requires a contiguous
memory block."

L1 cache is the exclusive workspace of the database engine. Any data
in L2 that needs to be accessed must be moved back to L1. There is a
bit of overhead moving the data from cache to cache so sometimes it is
faster without the L2. Data usage patterns, the amount of data, and
the amount of memory available (up to the 2GB limit imposed by the
operating system) determines just where that ballance point is. Top
to bottom reads of data files that do not fit in memory only incur the
overhead of without any benefits of L2. Also L2 does not allow any
dirty pages, so an application that is write intensive is not able to
take advantage of it either.

The minimum size requirement for L1 is dependent only on how big a
transaction is that needs to fit in memory. I have seen many NetWare
servers chugging along quite happily with the Novell NetWare install
default setting of 1MB. As of Pervasive.SQL 2000i many items you list
were moved outside the cache into their own dynamic memory space
including, file handles, user session information. Performance may
suffer but as long as there is no status 100.

Keep in mind the question was specifically for a server wth 4GB of
memory, of which there is a hard limit of 2GB by the OS, so turning L2
off can take advantage of all the memory in the server for caching.

Leonard

On Wed, 12 May 2004 11:11:18 +0200, Gordon
<grafzerk (AT) bigfoot (DOT) no.spam.please.com> wrote:

On Thu, 13 May 2004 05:46:53 GMT, Leonard <lharvey (AT) austin (DOT) rr.com>
wrote:

hmm, I guess you're never too old to learn. Missed that one - I see
you refer to the 8.1 whatsnew, was it also in the 8.0?

A lot more words than I used, but that was the point I was trying to
make

Are you sure? TMK everything that has locks on it needs to be in L1,
i.e. datapage + corresponding index pages + VL page(s) AND tableheader
+ PAT page(s). I agree that 1MB could be enough for the NetWare
environment and still handle an accidental administrator fondling with
Arcserve data. I have seen too many CPU-hogs on NetWare though to
accept that a minimum size requirement would depend on the size of one
single transaction, regardless of the number of users (each of them
doing their thing).

Did I misunderstand the section that said "we assigned 800 MB of the 1
GB memory"?


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

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

Hi,

we have set at Thuesday the "Cache Allocation Size" to 256 MB and
"MaxMicroKernel Memory Usage" to 50

since Thuesday the Server has no problems.

can it additional help to set the "MaxMicroKernel Memory Usage" to 0
and set "System Cache" on?

thanks

On Fri, 14 May 2004 11:06:48 +0200, Gordon
<grafzerk (AT) bigfoot (DOT) no.spam.please.com> wrote:

I believe so, but am not really sure. I doubt if something like that
would change for a service pack.
You are correct. I probably should have phrased it "all concurrent
transactions". It would not surprise me about locked pages either,
although strictly speaking I am not sure why a locked page would have
to be in memory, just a list to them including who has it locked. I
do believe lock information is kept outside cache (as part of the move
in 2000i to have cache exclusively file cache as opposed to being
treated as a memory pool before) but now will have to find out.
Yes the good old CPU hogs... I have seen many of those too, but the
CPU hog timer can be disabled if you don't want to give up the memory.
No I am not really recomending that, but it could be done. Better
answer is to just remove the CacheSize= line from the bti.cfg and let
the engine set itself to the default the next time.
Oops, one of us did and it was not you...

800MB probably is a little high for 1GB RAM

You can try it both ways and see which give better performance.

I would suspect that using the database caching will give better
performance than the generic file caching provided by the OS but you
just never know.

Leonard

On 14 May 2004 02:35:06 -0700, o.senzig (AT) pvs-limburg (DOT) de (OSenzig)
wrote: