If you're steeped in the world of technology, memory has specific meaning for you: it's your system's ability to store the data you give it. We're all over that kind of memory, and in this issue we give you tips on how to avoid memory fragmentationz–a nasty situation that occurs when your server has plenty of memory space, but can't process your requests.
Now think back to the days before you were steeped in technology–memory referred to your ability to remember important information (okay, maybe not-so-important information!). This month we give you some important stuff to commit to memory about how to manage those servers. We also have some great tips and tricks to help you resolve issues with GroupWise without resorting to technical support.
> Memory Fragmentation: Are You At Risk?
As a 32-bit operating system, NetWare can handle as much as 64 GB of physical RAM. Sounds great, right? But just because NetWare can handle that much memory doesn't mean your system will have that much memory to work with. Here's why:
Intel's 32-bit architecture limits any operating system to a 4-GB area in which logical memory can be mapped. Any memory that exceeds 4 GB must be accessed by mapping pages in and out of the 4 GB space.
Logical memory fragmentation occurs when the server has plenty of available logical mapping space for memory, but not in large enough chunks to grant a memory request. In other words, there could be 500 MB available, but if an NLM requested an allocation of 2 MB and the largest available size was 150 KB, the request would fail. The result? The server's memory is fragmented and the NLM would not run correctly.
Here's what that means to you: since most applications run in the "kernel space" or "ring 0" in NetWare–as opposed to "user space" or "ring 3" in other operating systems–all NLMs running in the kernel have a finite amount of RAM to work with. As a result, you might have to adjust the settings on your servers to reduce the number and frequency of memory problems, depending on the applications and NLMs you have running on the server.
There is an option: NetWare 6.5 Support Pack 5 with the added update NW65OS5A.EXE contains the latest fixes and updates you'll need to address memory fragmentation.
> Identifying Memory Fragmentation on a NetWare Server
Novell makes it easy for you to identify logical memory fragmentation on your NetWare server–simply use the statistics available through the Novell Remote Manager (NRM). Here's how:
- Open your browser and go to the server's IP address: 8008.
- You will be asked for a username and password; log in as Admin.
- Click View Memory Config.
- Scroll down to the Logical Address Space section.
- Note the value for "Fragmented Kernel Space."
You can also look at the red block on the graph, which shows the percentage of fragmentation. If the value (or block on the graph) remains steady over a period of several hours or several days–even if the percentage is as high as 50 percent–you don't need to tune your server. Steady numbers mean your server isn't compromised by fragmentation of logical memory.
If the value increases over time, or the red block on the graph steadily grows bigger, you should tune your server. I'll show you how.
> A Quick Aside: Diagnosing Memory Problems
Before you learn how to tune your server, you should be aware that fragmentation isn't the only memory problem you can have on a server. For example, any NLM on the server could "leak" memory–a problem generally caused by a module that allocates memory but then never returns it to the system. In other words, allocated memory is never freed up again once it should be available. As another example, a module might allocate an unnecessarily large amount of memory either by design or because of miscalculation.
Both of these situations will result in a dramatic decrease in the amount of memory available on your NetWare server. Both will also result in a steady decrease in the number of cache buffers reported in a Monitor.nlm. And both are clearly a problem, though neither is due to memory fragmentation.
The NRM utility is the best way to diagnose a memory problem. Under the Manage Applications heading, click List Modules. A list of all the NLMs running on the server will display, along with the amount of memory each NLM is using, broken down into different categories and sorted by how much memory each is using. If you see a module steadily climbing the list, suspect a memory leak.
If you think your server is leaking memory, make sure you have the latest version of the NLM. If that doesn't resolve the issue, contact Novell Technical Support for more help.
> Tuning Your Server to Prevent Memory Fragmentation
In just five simple steps, you can tune your server to address issues around memory fragmentation. These five steps address every possible factor that can contribute to or aggravate memory fragmentation–and you might not have to use all five. Try each one, in the order listed.
- Update Your Server
To begin, install the latest NetWare Support Pack on your server; the support pack includes all the fixes and updates for memory fragmentation issues. If you are running NetWare 6.5 Support Pack 5, install the NW65OS5A.EXE update. Once you've installed the support pack and the update, you should not have any additional problems with memory fragmentation. Depending on the amount of memory on your server, you may need to adjust settings as described in the next three steps.
- Reload the TSAFS Modules
There can be limits to the amount of cache the TSAFS module requests. To resolve any issues, unload the TSAFS.NLM module, then reload it with the following command-line switch:
The command-line switch specifies the percentage of the server's free memory that will be used by the TSAFS at run time. For example, if your server has 4 GB of RAM installed, the 1 in the command-line switch means the TSAFS call will allocate and use 1 percent, or as much as 40 MB of RAM.
- Set a Hard Limit on How Much RAM DS.NLM Uses If the DS.NLM consumes a large percentage of the RAM on your server, or if it uses more than 500 MB of RAM, you'll need to restrict how much memory eDirectory can use. To do this, install eDirectory 184.108.40.206 or later; earlier versions might not retain the
hard limit settings.
Basically, you can turn off the dynamic caching ability of DS.NLM, then hard set the DS RAM to start at two times the database size. Especially do this if your database size is less than 500 MB. The following technical information documents, or TIDs, describe how to hard set the amount of RAM eDirectory can use:
- Set the File Cache Maximum Size Parameter The hidden set parameter that determines the file cache maximum allows you to adjust the size of the logical memory spaces. With NetWare 6.5 Support Pack 5, use the following setting:
SET file cache maximum size=2147483648
Count carefully and make sure you've entered a total of 10 digits–just 1 extra or missing digit will make a huge difference. Note: If your server has less than 1 GB of RAM, you don't need to set this parameter.
Reboot Your Server
At this point, reboot your server and let it run for a few days or weeks; if possible, let it run through a cycle or two of peak user activity and a couple of automatic backup jobs. In most cases, fragmentation of logical memory will be resolved with the four steps described above. If you're still having problems, use the two parts of the next step, one at a time, to make the final adjustments.
- Adjust the Size of the User Address Space
If you are still experiencing memory fragmentation problems, alter the default size used for the User Address Space. Note: This step should be taken ONLY while the server is having problems, not when it is running smoothly or has been recently rebooted.
To alter the default, use a server startup command-line switch issued from the DOS prompt or added to the Autoexec.bat line that loads the server. Use "server –u < number of bytes for User Address Space size >" to give the memory configuration just what the server needs for the User Address Space–and no more. Be extremely careful with this setting. Count the digits in the number you provide the switch, and then double check the number. If you slip up and designate a number that is too low, CPU utilization will be high, and programs either won't load or won't run correctly in protected memory.
To access the feature, take the following steps:
- Open NRM and log in as Admin.
- Click View Memory Config in the left pane of the main window.
- Click Tune Logical Access Space.
- A screen will open and display configuration recommendations provided by the Novell kernel developers specific to your server's running condition.
- Make the recommended change, with the –u setting for server.exe (server-u < number >).
If your server has less than 3 GB of RAM, do not use this setting.
> Still Having Problems?
The five steps outlined above will take care of the most common factors that cause or aggravate memory fragmentation. If you're one of the rare exceptions, you might notice that the memory on your server steadily declines over the next month and that you have to keep rebooting your server, even though you followed these steps. If that's the case, your memory fragmentation problems have not been resolved.
Closely inspect your server to find out how much memory your NLMs are using. You might find that the NLMs are using more memory than the logical mapping size, and as a result, the NLM Address Space will borrow memory from the File System Address Space, causing a slow but steady decline in memory.
In virtually all cases, you'll fix the problem if you control the memory NLMs can use in the cache pool. Steps 2 and 3 above show two effective ways to control the memory used by specific NLMs. You might have to scrutinize other modules that are loaded on your NetWare server–either from Novell or from third parties–and adjust how much memory they are consuming on the server. To adjust and monitor memory consumption over time on a per-module basis, use the Novell Remote Manager (Module Listing) or other tools.
If you're still having problems or need additional answers, please contact Novell Technical Support.
> Maybe It's Your Application...
If you've applied the latest code and followed these steps, your memory issues might have nothing to do with your operating system–and everything to do with the applications that are running on your NetWare server.
To determine whether that might be your problem, check out the following documents (in TID format), which outline some of the most commonly reported issues:
Remember: your memory problems might be due to backup vendors, content vendors and other NLMs running on your server. It's critical that you identify the NLM where the memory problem exists and then contact the vendor that owns the module for a fix. To repeat: install the latest support pack and the updated patch from Novell. And, rest assured, Novell is continuing to make additional improvements in NetWare's memory management system to better accommodate the newest hardware configurations and the various combinations of modules you might be running on your server!
> GroupWise? Help Without the Support Call
You've come to appreciate GroupWise 7.0 as one of the premiere collaborative tools on the market. And if you've used Novell Technical Support engineers to resolve any GroupWise issues, you know how good they are, too.
From a support engineer's point of view, there's much to be said about the efficacy of a collaborative support tool, especially one that is easily leveraged by small businesses and enterprise concerns alike. GroupWise 7.0 is such a tool. Because they work with all types of configurations, support engineers wear plenty of hats, and they do it very successfully–even though one may have top-notch technical skills while another is more customer-savvy. They strive to resolve the customer, then the issue, and while the two mesh perfectly most of the time, occasionally they have to reconcile the needs of the software with the needs of the customer, which gives them a unique perspective on the product and the issues that cause support calls.
That said, they have some ideas on how you can troubleshoot many of your own issues without having to make a call. How would you like to save time and money by being able to check out some engineer-recommended documents, then do the troubleshooting on your own?
Then read on! The GroupWise support team has come up with a set of suggestions that will help you bypass the possible "gotchas" and points of failure that, despite every effort, appear in a small percentage of installations, upgrades and migrations. (Before you read this, they'd like to point out that they are acutely aware and respect the fact that some of you are far more skilled than some of them!) Ready? Here's what you can do before picking up the phone:
MAPI–Document Integration and Management
GroupWise 7.0 has moved away from the old Windows Messaging System. If you have Microsoft Outlook 2003, GroupWise 7.0 can use that MAPI. Check out the following TIDs:
- 10100406 – Getting Your MAPI Application to Work After Upgrading to the GroupWise 7 Client
- 10100675 – MAPI Services Dialogue Error
Many proprietary applications currently use MAPI to send information to the GroupWise client; an internal list of these applications is being modified as MAPI incompatibilities are addressed. As of the release of SP1, all (or nearly all) known MAPI complications have been addressed. I know I said you wouldn't have to call–but make sure you report any new issues to Novell Technical Support.
> Linux–Open Enterprise Server and SUSE Linux Enterprise Server
As Novell increases its presence in the open source community, many of its solutions are finding a place in the Linux world–including GroupWise, which currently runs well on Linux. The migration is becoming steadily more robust, and initial quirks have almost all been remedied. At BrainShare, Novell announced the GroupWise Migration Utility, which makes it much easier to migrate from NetWare or Windows to Linux. Until that product is available in mid-October, check out the following TIDs:
- 10099946 – Moving a Post Office to Linux
- 10099947 – Moving a Domain to Linux
- 10101095 – Documents Inaccessible After Move from NetWare to Linux
- 10100048 – POA, MTA and GWIA Becomes Unresponsive After SUSE Linux Enterprise Server SP3 Update
Note: GroupWise 7.0.1 has alleviated most of this, but the backrev may be a necessary step in certain types of troubleshooting.
The robustness of GroupWise 7.0 in a shared resource environment has greatly improved. In both Linux and NetWare, GroupWise is basically an application residing and performing its actions in a memory space making the main issue the ability of the resource to failover from one node to another while maintaining memory space. While that ability is fairly stable, there are some considerations around GroupWise clustering in native Linux file systems. For help, check out the documentation at novell.com/documentation/gw7/index.html.
Note: Native Linux file systems house GroupWise well in a cluster, but some stability issues exist in some scenarios. Novell is investigating these scenarios.
> GroupWise WebAccess
GroupWise WebAccess 7.0, which has a slightly different interface and home page, uses Tomcat 4 in NetWare and Tomcat 5 in Windows. Access https://< server_ip >/gw. Note that WebAccess can't utilize secure communications via Public/Private keys; only the online client can.
> GroupWise Internet Agent (GWIA)
While it is lacks some features, changes to the GWIA have made it robust in most ways and have maintained its compliance with increasingly stringent security protocols that guard today's mail gateways, including SPAM filters. Just remember: GWIA is not intended for use as a firewall or a relay host, just as GroupWise itself is not meant to be a content management system. GroupWise 7.0 allows for more control than what was available through the Access Control List and the Mailer Daemon, but that control is collaborative when used in conjunction with SPAM filters and/or firewalls. Check out these TIDs:
- 10100683 – Rule-generated Messages Don't Deliver to Recipients Properly
- 10099640 – GWIA Abends the Server When Loaded or Unloaded
The previous method, TSA600.NLM, GWTSA.NLM, is no longer a supported configuration. Instead, use TSAFS.NLM, TSAFSGW.NLM. (While it is supported, TSAFSGW.NLM has some kinks that affect how it works with the GroupWise 7.0 GWENN5.NLM). Check out the following TID:
- 10095865 – It is not necessary to use the TSAFSGW.NLM at any time. A full backup can be garnered by using TSAFS.NLM with the /enablegw=yes switch in the TSA.CFG.
> GroupWise Archive
Novell's current archive structure is robust, but only in a general way. It is difficult to centrally store archived data and maintain its integrity over a number of years, especially in today's environment, where many companies might need to work together to maintain historical collaboration. That's not all: large post offices of more than 100 GB get difficult to back up, maintain and restore.
Remember: As the size and age of your GroupWise stored messages increases, so does the chance for failure. If your system is left too big for too long, without systematic efforts at cleaning and maintenance, you risk the loss of valuable data.
If you need to maintain vast amounts of data in nearline storage, there are reasonably priced third-party applications that can both store GroupWise historical data and easily restore it as needed.