Pervasive Memory Usage
Received from Pervasive support on June 11th 2010
By Phil Cavanagh
If the server has less than 2 GB RAM, the default
settings are sufficient. Verify that the Max Microkernel Memory Usage is set no higher than 60%.
If the server has 2GB or greater RAM, set Cache Allocation Size in the servers configuration under Performance Tuning
to 40% of the servers RAM. The setting for that is in bytes. Set the Max Microkernel Memory Usage to 0. That disables the dynamic file caching.
Under the category Memory Usage set System Cache to
On. That allows the engine to use the OS file caching instead of the dynamic caching above.
----------------------------------------------------------------------------------
The Pervasive.SQL version
8.x/9.x database engine on Windows allocates two separate pools of memory for caching data named Level 1 (L1) and Level 2 (L2) cache. The L1 cache is a static amount and is used for storing inserts or updates that need to
be written to disk, as well as storing recently used data to be re-read. When the L1 memory becomes full, stored data is moved from the L1 cache into the L2 cache. The data that is stored in L2 is compressed which
increases its effective capacity.
Data pages are uncompressed and moved from the level 2 cache to the level 1 cache for processing read or change requests.
One exception is that the page server, which is the
server side element of the client cache engine, can read the compressed pages in L2 directly and deliver the contents in the compressed format to the client cache engines.
There is also memory required by the
Pervasive process to manage data structures such as file lists, locks, user or client lists, cache management, and disk I/O. This memory for data structures, the L1 and the L2 caches are consumed under the umbrella of
Microkernel Memory. Windows task manager will show this memory used by the NTDBSMGR.EXE process. The task manager has two additional Pervasive processes listed; NTBTRV.EXE for the transactional (Btrieve) service,
and W3SQLMGR.EXE for the relational (ODBC) process. These two processes are essentially only used to stop and start the services, and their memory usage is very small and static.
The cache sizes are configured
using two settings in the configuration utility, Cache Allocation and the Max Microkernel Memory Usage.
|-- Level 1
--| Cache Allocation, default: 20% of the
systems RAM
|-- Level 1 --| |-- Level 2 ---->| Max Microkernel Memory Usage, default: 60% of
the
systems RAM or 60% of 2 GB.
|-------------- System RAM --------------|
The level 1 cache size is a fixed amount and is set in the configuration utility using the Cache Allocation
setting.
The maximum level 2 cache size is set indirectly through the Max Microkernel Memory Usage setting. This setting states that the level 1 and the level 2 caches plus the data structures combined can grow no
larger than 90% of the system RAM, up to 90% of 2 gigabytes. On the Windows operating systems there is a per-process limitation of 2 gigabytes. On some of the higher end OS's such as Windows 2000 Advanced
Server, XP Professional, and NT 4.0 Server Enterprise edition, there is an option to allow 3 gig, which configures the system so that an application can request up to 3 gig. Pervasive.SQL version 8 is "large address
aware" and can used with the 3 gig option. If the server does have this enabled, Pervasive will correctly calculate the cache default percentages based upon 3 gig.
This setting is adjustable, and if
it's set smaller than the percentage used by the level 1 cache, that will effectively disable the use of the level 2 cache. Setting this value to 0% will disable the use of level 2 cache, and will also automatically
enable the use of System Cache, which is the operating systems cache. In one situation this may be preferable, which will be discussed later.
The level 1 memory is allocated, but not particularly used by the OS all
at once at database startup, while the level 2 memory is allocated or de-allocated as needed. At startup, there will be nothing allocated for level 2. As data is read from the disk, it is stored in the level 1
cache, and only when the level 1 cache fills will the data then get moved to and stored in the level 2 cache. As more data is read from the disk, the amount of memory used by the level 2 will grow, and can only grow to a
point where the Microkernel Memory Usage combined equals 90% (default) of the systems RAM. If the OS at any time requires more system memory for another process, the level 2 cache will discard pages or data releasing the
memory back to the OS. If the Microkernel at any time requires additional memory for file lists, locks, or cache management, the level 2 cache will discard pages or data to release memory for that.
Outside of the
Microkernel, the NTDBSMGR.EXE process will also need to allocate memory to manage things such as the SRDE or ODBC processes, network communications and client session information, and linked products if installed such as
Pervasive DataExchange and Audit Master. These resources are separate from the Microkernel memory and these additional resources are not calculated within the Maximum Microkernel Memory setting. At peak usage, the
NTDBSMGR.EXE processes memory usage will include the Level 1 and Level 2 caches, and the data structures, which using default settings will not exceed 90% of system RAM, plus any memory used by ODBC, networking and linked
products.
Memory is allocated from the OS using the VirtualAlloc API. Using this method, a process first reserves memory. This memory is reserved in the virtual memory space. Not until the memory is
committed or used does it actually map to physical memory and consume RAM. The Windows Task Managers Memory Usage column displays the amount of physical or committed memory in use by a process. Therefore,
particularly at startup, the NTDBSMGR.EXE process may show a memory usage value less than level 1 cache amount and not equal that until data pages are read from disk and stored in the cache which commits the memory.
The
data files page will remain in cache if possible even though the file is closed. Once re-opened, a CRC comparison on the file will be done to ensure that the file has not changed and the contents that are in cache are
still valid. If the "Back to Minimal State if Inactive" setting is set to Yes, 30 seconds after the last client disconnects the Microkernel will free the resources it's using by discarding any data pages in
it's caches and return the memory to the operating system. In low usage, low memory situations this may be desirable, although on a dedicated server with sufficient resources it is beneficial to have this value set to
No in order to retain the data that's stored in the cache until it's needed again. There is a companion setting of "Allocate Resources at Startup" which tells the Microkernel to allocate resources when the
service is started. Note that in this situation the memory for primarily the level 1 cache is allocated, although not committed and such will show in the Task Manager at service startup as used by the virtual memory, not
under the Memory Usage column which is physical memory. The default setting for this is On, and should only be changed in low usage, low memory situations.
A situation can occur where the Microkernel or
NTDBSMGR.EXE can run out of memory. If the level 1 and the level 2 caches, and the ancillary resources grow to consume either nearly all of the available memory or near to the 2 gig per-process limit, and the NTDBSMGR.EXE
needs to allocate additional memory for handles, clients, or ODBC, there is no mechanism to signal the level 2 cache to back off and release some memory for this to take place. Depending on the resource needed, it's
possible to receive resource or memory errors in the pvsw.log such as VirtualAlloc(lstnBuf) error=8, but more commonly the result is for a hang to occur. The hang could occur with only ODBC users, only new users, or even
all users. It's also possible, although rare, that a Dr Watson could occur.
To avoid this, the Max Microkernel Memory Usage setting should be lowered from the default of 60% or 90% to a lower value, which will
allow a larger buffer of free memory to exist. An optimal value that will maximize the use of memory or caching is impossible to predict, but 60% has worked effectively and can be used as a baseline. In a high
resource or low memory situation, the level 2 cache could be disabled altogether through setting the Max Microkernel Memory Usage to 0. In that situation, the "System Cache" setting should be set to On which will allow
the operation system to provide additional caching. With server engines the System Cache should not be enabled when the level 2 cache is being used to avoid an inefficiency of double caching files. System Cache
defaults to off, unless the Max Microkernel Memory Usage is set to 0% where it will automatically be enabled.