Archived Content: This information is no longer maintained and is provided 'as is' for your convenience.
NetWare 6.x Memory Fragmentation & Tuning
NetWare 6.0 SP5
NetWare 6.5 SP2
NetWare 6.5 SP3
VM Pool is extremely large.
Memory allocation errors configuring NSS /MinBufferCache
Short Term Memory Allocation Errors during boot.
Applied NetWare 6.0 SP 5 or NetWare 6.5 SP2
Background: Address Spaces.
A NetWare server has three logical address spaces.
- The File Cache Pool. This is the logical = physical range. This is where NSS runs and it is defined by the set parameter "File Cache Maximum Size".
- The user address space is used for Protected Mode Applications, including Java, and can be controlled by the -u setting on the server.exe command line.
- The Virtual Memory (VM) Pool is the logical space where NLMs generally run, and it's size is 4GB minus the user space and File Cache Maximum Size.
The VM pool is now, and has been since 5.0, the main cache for all memory allocations except for NSS and a few NLMs which require logical = physical memory. The VM cache pool will fulfill all memory requests, even logical = physical requests when it has it. The VM cache pool also provides all stacks, NLM code and data, along with backing the virtual memory system.
If however the VM system can not provide the requesting NLM with the requested memory, then memory will be scavenged from the File Cache pool for use by the NLM. When the NLM is unloaded, or it reduces its memory requirements, the memory manager will assign only some of the memory back to the File Cache Pool, resulting in fragmentation of the File Cache Pool, and a reduction in available memory in the pool.
So say you have a user space size of 1 GB, and the File Cache Size is set to 2 GBs. NLMs would have 1 GB of logical space to use before they started to share with NSS. There is always some fragmentation, so that leaves about 800 MB for NLMs. If the peak NLM allocations was 1.2 GB, you would need to decrease either the user space size, or the File Cache Maximum Size to free up more space for the NLM Logical Address space.
The NetWare servers memory management system is designed to transfer memory to where the memory is needed. At boot 1GB of memory is allocated to the File Cache Pool, and the rest for the VM Pool. As the server is utilized - clients making requests to NSS, NLMs being loaded and unloaded, or requesting then freeing memory, the Memory Manager will reallocate memory to where it is best utilized.
If NSS requires more that the 1 GB of memory the VM system will move memory down to satisfy NSS, as long as the NSS size is not statically configured. If NSS doesn't need anymore, the VM system will hold onto the available memory, as requests for NLM memory vastly exceed the number of requests for NSS memory. The server will adapt to the load placed on it. If the VM system is holding all the memory it is usually because NSS has not asked for it.
As stated, at boot time the File Cache Pool is set at 1GB, then once the registry is opened the File Cache Maximum Size is set. This set parameter sets a logical (not physical) space limit on how big NSS can grow. NOTE: Setting the File Cache Maximum Size (FCMS) parameter does not immediately allocate that memory to the pool, it sets a limit on how large the pool can grow. This has led to some confusion as administrators expected the memory to be in the pool, but found that the memory wasn't available.
One other common point of confusion comes from the fact that the size of the memory pools, individually or collectively may often exceed the physical memory installed in the server. Remember that these pool sizes are logical sizes not physical. A server with 0.5GB of physical memory can still have a logical poolsize of 1GB or more. The File Cache poolsize is a limit to how large the pool could grow to, presuming there is that much memory, and the file cache requires it, not the current physical size of the pool. The VM Poolsize is a derived figure: 4GB - File Cache Poolsize - User Space, and will almost always be greater than installed memory on any server with less than around 2GB of physical memory.
Background: Memory Fragmentation
Memory fragmentation occurs as the initially contiguous blocks of memory are broken into smaller blocks and assigned to the different pools. As NLMs are loaded or request memory, the memory manager provides them with a contiguous block of memory equal to the request. When the NLM is unloaded or the memory released, the memory manager takes the returned memory and reallocates it as required, and as the server is configured.
For example: A loaded NLM requests a 10MB block of memory. The memory manager locates a suitable block and gives it to the NLM. Later, the NLM will be done with the block of memory, and return it to the memory manager. The memory manager will look at the server requirements of the server and reallocate the memory as necessary. If NSS is set to CacheBalance=80% and is requesting more memory, then the memory manager will give 8MB of the block to NSS, and return the other 2MB to the VM pool. Our once contiguous 10MB block of memory is now broken into an 8MB and a 2MB block.
As more and more of the memory is broken up, or fragmented, the available contiguous memory will drop, and in the worst case, will drop to a point where there is very little contiguous memory in the VM Pool. There could potentially be hundreds of megabytes there, but all of it broken into very small blocks. So, although there should be "plenty" of memory in the VM Pool to satisfy memory requests, the fragmented nature of the memory means that there is insufficient contiguous memory, and the memory allocation will fail.
Note that memory fragmentation is normal, and will occur to some extent on all servers. Its only when the memory becomes so fragmented that the memory manager cannot allocate sufficient contiguous memory to fulfill a request that it becomes a problem. This will generally not happen on most servers, as it requires many large memory requests/releases to occur.
To address the problem on servers where it is occurring, there are two tuning options available that will limit the impact of memory fragmentation.
The first is to statically configure NSS to a fixed size, and is discussed in more detail below, but basically, by statically allocating memory to NSS, when a memory block is freed it will be returned intact to the VM pool as the NSS pool will not be requiring any additional memory. This is an effective method of limiting the fragmentation, but does have its drawbacks as discussed below.
The other method is to use the "File Cache Maximum Size" setting to limit how much memory can be allocated to the NSS pool. Using this method only memory in the range 1GB - FCMS will be allocated to NSS, preventing fragmentation of the memory from FCMS to the top of memory due to the memory being allocated to NSS.
Note that neither of these methods will totally eliminate memory fragmentation - memory in the VM pool can still become fragmented, though the impact is generally less.
Background: NSS Static Mappings.
As stated above, statically assigning NSS memory is a workaround for fragmentation problems when NLMs allocate large amounts of memory, and you want to limit the amount of logical space NSS uses. It shouldn't be used to give NSS more memory. NSS rarely needs, but will happily use, more than 1GB, and by letting it allocate and free memory dynamically it can run most optimally. This way if NSS needs more, it would be free to ask for more, with a static assignment NSS has to work with what its been allocated.
There are two problems with statically assigning cache to NSS:
1) One of the consequences of the introduction of the 1GB File Cache Pool limit at boot is that it is not possible to statically allocate 1GB or more of NSS cache at boot, even with the FCMS set to more than 1GB. As stated, there is only 1GB in the pool at boot, the FCMS is just the maximum size the pool can grow to with a dynamically resizing NSS. The pool will only grow as NSS requests memory, and a statically configured NSS will not request any more memory.
2) Any memory in the server in excess of the memory used for NLMs and the 1GB in the File Cache Pool will never be used.
Say you have a 4GB server, that has a peak NLM load of 600MB, and NSS statically configured. 1GB of memory will be assigned to the File Cache Pool, 600MB will be allocated to NLM's, the remaining memory will sit in the VM pool and never be accessed or utilized.
If instead NSS was configured for dynamic growth, with FCMS set to 2GB, NSS will grow as the server is utilized, with memory migrating from the VM pool to NSS.
There are no hard and fast rules on how a memory should be configured, each server is different and may have specific configuration requirements. These recommendations are a guide only, and may require tweaking for specific situations.
Small Memory Servers: ( <= 1.0GB Memory)
Set the tuning parameters to:
Set File Cache Maximum Size=1073741824
If you suspect that memory is becoming badly fragmented, which can still happen with these settings, separate the two memory pools by statically configuring NSS. From NRM get the maximum NLM footprint and set NSS to less than total memory - NLM footprint.
eg: With a 1GB server, and a 400MB NLM memory footprint we want to set NSS to less than 600MB, so use:
This will set NSS to around 400MB of cache, leaving 200MB for traditional memory and other memory requirements.
Medium Memory Servers (1.0GB <= Memory <= 2.0GB)
Do nothing, the default settings are generally fine. If they have been changed, reset to:
Set File Cache Maximum Size=2147483648
If you suspect that memory is becoming badly fragmented, which can happen with these settings, separate the two memory pools by reducing the FCMS parameter. From NRM get the maximum NLM footprint and set FCMS to physical memory - NLM footprint.
eg With a 2GB server and an 800MB NLM footprint, set FCMS to around 1.2GB:
Set File Cache Maximum Size=1288489984
If the FCMS would be set to less than 1GB, instead drop FCMS to 1GB, and statically configure the NSS cache as for the small memory model server.
Large Memory Servers ( > 2.0GB Memory)
Use NRM to determine your peak NLM Memory footprint. Under the Manage Applications heading, click on List Modules, which displays a list of all the NLMs running on the server and amount of memory each NLM is using (broken down into different categories). If you observe a module steadily climbing the list of modules (sorted by memory usage), that NLM is a suspect for a memory leak. To address NLMs with a memory leak, the latest version of that NLM is needed. If the latest version does not fix this issue, please contact Novell Technical Support for further help.
As a general guide set the parameters as:
Set File Cache Maximum Size = (Total Server Memory) - (NLM Size) - 1GB.
If the NLM Peak memory usage exceeds 1.5GB, then use the tuning steps in KB 10091980.
After applying any of the changes above it necessary to reboot the server.
If you go into NRM and view the memory config shortly after boot, you'll see that the VM Pool is still very large. This is NORMAL. NSS has taken its initial allocation of memory, and as the server settles into its normal load, memory will be migrated from the VM Pool into the other pools as required.