The use of NetWare Loadable Modules (NLMs) is but one way in which resources can be dynamically allocated and released by NetWare. Failure to properly manage NLMs or to ignore their resource allocations is also the quickest route for NetWare's dynamic allocation capabilities to work against it. Thus, proper NLM management can be as crucial to Server performance and integrity as the availability of RAM and selection of hardware. To better appreciate how NetWare memory management works, it is important to have a basic understanding of how the NetWare memory architecture works.

NetWare allocates and consumes flat memory space up to the limits of its 32-bit addressing limits (i.e., 4 Gigabytes of memory). As a result, all system threads (or processes) and associated data share the same memory space. NetWare views the memory as one large block of memory that is divided and distributed to the various system threads and associated data pools as required.

In NetWare v3, an NLM's static code requirements is the first memory allocated followed by its static data area. These two pools typically reside as contiguous blocks in physical memory. Subsequent data requirements that are greater than or equal to the defined Cache Buffer Size are allocated from the Cache Buffer pool while the Short Term Alloc pool is used to satisfy smaller requests.

Since there is no restrictions on the pools which NetWare sees as a single block of memory, it is possible for an NLM to overwrite its data or stack and corrupt the code it contains or that of bordering NLMs. Such overwrites are often the most difficult Server failures to diagnose and isolate.

With the advent of NetWare v4, Novell introduced a new memory management scheme that maps page-aligned contiguous blocks of memory into address space which is actually beyond the physical limits of the system. Under this scheme, each NLM can be allocated protected memory to satisfy its static data requirements. This protection can help reduce the possibility that an NLM might write beyond its data space and corrupt another NLM. However, it does not eliminate the prospect since much of the Server kernel data areas must be shared and is available to all the NLMs, both for read and write access.

NetWare's internal allocation of memory to satisfy the subsequent needs of running system threads, as well as the loading and unloading of NLMs and their allocation of temporary memory resources, can result in significant memory fragmentation and subsequent performance degradation. Thus, contrary to popular belief, it can be advantageous to down the Server periodically in order to reset the base of allocated resources.

Fortunately, the frequency of memory fragmentation can be reduced by proper Server tuning through the Setable parameters and logical NLM management. While an entire chapter of a book could be dedicated to either subject, space restrictions allow for only a brief overview of logical NLM management.

Without over complicating the issue, there are two keys to the logical management of NLMs which are not really complex. First, it is important to realize the interdependencies of all the NLMs which will be loaded. Secondly, knowing whether or not the NLM may be unloaded during normal Server operation is significant. To reduce memory fragmentation and improve code performance, NLMs should be loaded in an order based upon the following criteria:

1). Are other NLMs dependent upon this NLM?
For example, the STREAMS and CLIB NLMs should be among the first NLMs loaded, if required by any of the other NLMs, since they are not likely to be unloaded.



2). What resources are likely to be allocated by this NLM?

Through the MONITOR NLM, it is possible to view the resources allocated by an NLM (select the System Modules option and then choose the desired NLM). Key resource allocations to track are the memory allocations since many NLMs may have small footprints (i.e., small load size due to minimal static code and data allocations) but large dynamic memory allocations. Consistently increasing or irregular memory allocations will further exacerbate memory fragmentation.


Whenever possible, load NLMs which make large or frequent dynamic memory allocations as late as possible in the load order. This will help reduce memory fragmentation.




3). Is this NLM likely to be unloaded at some point?

NLMs which are unloaded out of order can fragment memory. These fragments may be allocated for Cache Buffer use or smaller NLMs before the original NLM can be reloaded, further fragmenting memory. A rule of thumb is to load those NLMs which may need to be unloaded at the end of the loading sequence.


Whenever possible, it is also advisable to unload NLMs in the reverse order of which they were loaded. By so doing, memory usage is maximized and fragmentation is minimized. The following example illustrates this concept:


At load:


LOAD AVANTI
LOAD XYZ
LOAD MONITOR




To unload AVANTI:


UNLOAD MONITOR
UNLOAD XYZ
UNLOAD AVANTI
LOAD XYZ
LOAD MONITOR

In short, NLM management is like rearranging a stack of blocks. Start with a stable foundation (NLMs which won't be unloaded) and be careful how often you remove blocks from the middle of the stack and reload them on the top. Too much block shuffling will threaten the stability of the stack and may cause it to come tumbling down.