05-26-2004 09:13:50 W3COMSRV 0000177C NTDBSMGR.EXE SERVER
VirtualAlloc(lstnBuf) error=8.

Hi we just encountered this error on our Windows Server 2003 and
Pervasive 8.5 Server in the pvsw.log. There where about 184 of them in
a few minutes before the server engine locked up.

Does anyone know anymore than is posted in the knowledge base under
psql5287?

The server has 6gb of ram, and the server had about half of that free.
Max

MicroKernel Memory Usage is set to zero.

Any suggestions welcome

Mike

From an earlier post:
By your statement that about 1/2 was free means that about 1/2 is
used. You did not mention how much memory was used by the database
process or what the regular CacheSize setting was set to.


The operating system limits the total address space of a single
application to 2GB. The Pervasive.SQL database engine runs in a common
memory space and is limited to 2GB of address space.
Note: Some versions of Windows support the /3GB boot.ini switch and
will allow a process 3GB of address space instead.

The Pervasive.SQL database memory management monitors free physical
memory (until the patch is installed). On servers with 2GB or more of
memory there may still be significant physical memory free; when the
Pervasive.SQL database process has allocated its entire 2GB of address
space, this potentially causes further memory allocation calls to the
OS to fail even though physical memory is still available.

The situation is further complicated as the operating system reserves
1 MB of address space per thread the application starts for stack
space out of the 2GB limit. Additionally, since the memory is only
reserved it is still reported as free. With the default thread
settings, this is typically peaked at 50 threads that yield 50MB of
memory that cannot be used for any purpose but stack space. A higher
thread setting increases reserved memory.

When to not use the dynamic cache:
There are server configurations that may provide better overall
throughput using the operating system caching instead of the dedicated
database caching. This is independent of the above-mentioned issue
that can occur if memory is not freed for other applications on the
system. Simply put, this is a fact of the most efficient use of memory
when physical memory exceeds 4GB of RAM. Windows limits an application
to 2GB of RAM, and the MicroKernel uses data optimization to better
fit and access data in the same amount of memory. But Windows itself
can use more than the 2GB limit it places on processes, thus it is
possible to achieve higher performance metrics by allowing the OS to
control and monitor all the caching and being able to cache more
database records if the memory is available on the system. You can
turn off the dynamic cache using the Configuration setting, "Max
MicroKernel Memory Usage", and turn on the "System Cache".

So for your specific server the short answer is to set the "Max
MicroKernel Memory Usage" = 0, and set "System Cache" = "on"

Leonard

On 26 May 2004 02:02:25 -0700, miketrill (AT) uboot (DOT) com (Mike Trill) wrote:

Leonard,

Thanks for the reminder, we had already taken note of your ealier
suggestion
so out settings are as below :-

"Max MicroKernel Memory Usage" = 0
"System Cache" = "on"

We have found a possible cause, the crashes. The server runs fine,
until we copy files to the btrieve server using 'xcopy' from a cmd
window on the server. By large I mean 2 to 4gb.

We may try and replicate this, before we do a scheduled shut down at
some point.

Mike