Memory tuning on NetWare 65

From MicroFocusInternationalWiki
Revision as of 04:10, 31 March 2006 by Hspeirs (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a frequent post in the forums. For a full description of what needs to be done, check out the cool tool Hamish Speirs wrote. The article includes a good description of what he is doing, as well as how he arrives at the numbers he posts in the forums.

From the article:

In recent NetWare 6.x Service Packs, the memory management with NetWare has undergone a rather radical overhaul to help address limitations NetWare was starting to experience under intensive loads - e.g., Running large databases, multi gigabyte eDirectory trees with millions of objects, multiple Java applications etc.

These changes to memory management were initially quite problematic, but have become much more reliable in the current service packs - except, in my opinion, for the "auto tuning" feature that is enabled by default. The Auto Tuning feature monitors the memory usage on the server and adjusts two parameters to try and free up more logical address space on the server. For more information on Logical Address Space refer to

The AutoTuning feature operates by lowering the "File Cache Maximum Size" (FCMS) setting, which controls how much memory is available to the server for use as NSS and/or TFS cache. If the FCMS setting reaches its minimum possible value of 1GB then the auto tuning will then start recommending that the "-u" setting is reduced. The "-u" setting controls how much space is available for the "User Address Space". This is a logical memory region that is reserved for running protected mode and Java applications.

In my opinion, the memory tuning algorithm is too aggressive, and too simplistic:

  • It wants to keep too much memory in the VM pool.
  • It's too keen to drive the FCMS setting down.
  • It will only "tune" in one direction, and it "tunes" the server to accommodate one off memory allocations - an NLM accidentally requesting a 1GB allocation today will mean a server "tuned" for that size memory footprint a year from now. If I remove a large memory footprint NLM from the server, memory will not be "tuned" back towards a larger cache- the memory will be forever reserved for the VM pool.
  • The "tuning" can result in even more memory fragmentation than the tuning is designed to prevent. When the FCMS setting is reduced, the complete NSS cache is thrown away (flushed), then its starts growing again. I've seen servers with 2-3% of fragmented memory suddenly have 15% or more after being "tuned".
  • The tuning can cause server abends. I've seen it cause Poison Pill abends on Cluster nodes, and other abends on standard servers.

This aggressive auto tuning in addition to some "interesting" default settings bias the server towards giving excessive memory to the VM pool at the expense of the FS Cache pool.

For the complete details go to

A series of calculator utilities to determine better manual tuning settings for the server are available from

Version are available for Linux, Win32 and NetWare 6.5

The Linux and Win32 versions require a SEGSTATS.TXT file from the server and will recomend the changes to be made. The NetWare version does not require the SEGSTATS file, and can make all the necessary changes to the server.