SERVER MEMORY: Understanding Memory Fragmentation in NetWare Servers
Articles and Tips: article
01 Apr 1995
When new volumes or NLMs can't find enough memory to load or operate, sometimes memory fragmentation is the cause of the problem. Here's some background information that should help you understand the underlying causes of fragmentation in NetWare 3 and 4.
All operating systems struggle with memory fragmentation issues and each has its own methods of dealing with the problem. Fragmentation naturally occurs when available memory is divided into smaller pieces and portioned out to multiple OS subsystems and applications. The impact of this resource sharing is the waste that occurs when some memory becomes unusable. This waste is termed external and internal fragmentation.
NetWare 2 and 3 operating systems didn't use memory mapping and operated solely out of physical memory. This meant that they had no way to reorganize non-contiguous blocks of physical memory into contiguous blocks of logical memory. For example, in Figure 1a, a contiguous block of memory is divided up and allocated by processes A, B and C. When process B frees its memory (Figure 1b), the memory becomes available for others to use. But when C requests a single memory block the same size as the two blocks of memory released by B (Figure 1c), the memory is unavailable because it is non-contiguous. This is called external fragmentation because memory blocks external to your request create gaps that can't be collapsed and used as contiguous blocks of memory.
Figure 1: External fragmentation in physical memory.
NetWare 2 and 3 memory problems were often produced by external fragmentation. The server had plenty of memory but, over time, external fragmentation reduced the possibility of satisfying requests for large contiguous blocks of memory.
NetWare 4 uses a mapped memory architecture which means many of the limitations of physical memory, including some related to external fragmentation, have been removed. But even a mapped memory architecture produces frag-mentation. In NetWare 4, contiguous blocks of memory are divided into 4KB pages. When OS subsystems and NLMs allocate memory, their requests are satisfied in 4KB blocks. (See The NetWare 4 Memory Architecture, April 1995, for an explanation of how NetWare 4 organizes memory.)
For example, in Figure 2, when process A requests 5KB, the OS uses two 4KB blocks to satisfy the request. In this case, the 3KB of leftover memory won't be used unless process A requests a memory block less than or equal to the size of the leftover memory block. This wasted memory is said to be caused by internal fragmentation because the wasted memory is internal to the memory allocated by the requesting process. However, when process A frees the 5KB memory block, the entire 8KB is returned to cache. So internal fragmentation is much more manageable than the irreversible external fragmentation described earlier.
Figure 2: Internal fragmentation in mapped memory.
NetWare 3 Memory Fragmentation
Because NetWare 3 does not use any memory mapping, the OS, OS subsystems, and all NLMs contribute to external memory fragmentation. In most NetWare 3 server con-figurations, this isn't a noticeable problem. But in some configurations that include large volumes, removable volumes, and NLMs that rely heavily on NetWare's Alloc subsystem, external fragmentation can pose a serious problem. In some cases, the server must be brought down and rebooted to eliminate the effects of fragmentation.
If this is the case, we suggest that you upgrade to NetWare 4.1 immediately because the causes and effects of external fragmentation have been greatly minimized in NetWare 4.
NetWare 4 Memory Fragmentation
Due to NetWare 4's mapped memory architecture, much of the fragmentation that occurred in NetWare 2 and 3 servers has been eliminated. The NetWare 4 operating system code and data pools are all mapped into logical memory, which eliminates external fragmentation. At some time in the future, most or all of the server's software components will use logical memory to avoid the effects of external memory fragmentation entirely. Here are the two exceptions for NetWare 4.10:
NLM Data Segments.
NLM data is still placed in physical memory and therefore deals with the effects of external fragmentation. Most NLM data could now be loaded high, but some I/O-related drivers are slowing down the migration to logical memory. Older adapters, many of which were designed for the AT bus, have a 24-bit address path. That means they can't address anything above 16MB. By itself, that doesn't keep us from loading the adapter's shared memory high. It's the driver that isn't designed to handle physical-to-logical address translations during DMA operations that's causing the problem. As soon as these drivers begin to disappear, we hope to see a version of NetWare that uses logical memory for everything and does away with external memory fragmentation.
Moveable Memory Subsystem.
This subsystem allocates memory for a variety of OS tables including file allocation tables (FATs), directory hash tables, and connection tables. Up to and including NetWare 4.1, the moveable memory subsystem was confined to the high end of physical memory.
Residency in physical memory and the related effects of external fragmentation have been a frustration for users with large volumes, especially large removable volumes. After mounting and unmounting a volume several times, the resulting fragmentation of physical memory made mounting the volume virtually impossible.
To solve this problem, Novell has shipped HIMOVE.NLM. You can find this NLM on your NetWare 4.1 master CD in \NW410\BOOT\NWOS2\HIMOVE.NLM. When HIMOVE is loaded, it allows the moveable memory subsystem to use logical memory and avoid external fragmentation. In subsequent versions of NetWare, HIMOVE will be integrated into the OS and this subsystem will use logical memory and no longer deal with the effects of external memory fragmentation.
For the present, HIMOVE shouldn't be used with device drivers that use DMA and don't do proper physical-to-logical address translations, as described above.
If you're not sure whether your disk driver is using DMA or whether the driver is handling physical-to-logical addressing properly, you'll have to test the driver. Using a blank hard disk, perform these steps at the server console:
Load the disk driver.
Create a NetWare partition and volume.
Mount the volume.
Dismount the volume.
Mount the volume again.
If the driver isn't properly handling physical-to-logical addressing, the volume's FAT will be corrupted during Step 5 and the volume won't mount in Step 6.
Other Memory Limitations
Some memory limitations aren't caused by fragmentation at all. For example, some are caused when a data structure is too small for new configurations or applications. This is the case with a memory limitation for NetWare. Theoretically, NetWare is capable of using the full address space supplied by the CPUC4GB in the case of the 386, 486, and Pentium CPUs. But NetWare 4.0 allocated memory for a cache control structure that was only large enough to control 480MB. Errors seen with more than 480MB weren't caused by memory fragmentation, but simply an insufficiently sized data structure. The NetWare 4.1 cache control structure is now capable of handling up to 3.75GB of memory in the server.
Another memory problem is created by EISA servers, some of which don't automatically register memory above 16MB. If you have more than 16MB in one of these machines and run into memory errors, see Register Memory in NetWare 3.x and 4.x in Novell's Network Support Encyclopedia (NSEPro) for step-by-step instructions.
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.