Tuning OES NetWare for Write Performance

  • 3660811
  • 08-Feb-2008
  • 27-Apr-2012


Novell NetWare
Novell Open Enterprise Server (NetWare based)
Novell Storage Services (NSS)


  • How to tune a server for best write performance
  • Hints, tips and tricks to tune a write-biased server
  • Writing, copying or moving files is slow
  • Optimising/optimizing write performance
  • High utilisation/utilization or poor performance when copying to server


In normal usage, users generally do more reading from servers than writing to them. The standard out-of-the-box configuration can often deal with this without further manual tuning. There are circumstances, however, where a server may be subjected to a great deal of writing. In extreme cases the server can become unresponsive and cause bottlenecks where clients slow down or disconnect.

The following tips are all based on real-world experience and can help improve the performance of servers in a write-heavy role. Not everything here may be appropriate in your environment. You need to understand where the bottlenecks are and address those on a case-by-case basis.

  • Baseline your server so that you know whether you are making things better or worse
  • Ensure that a consistent set of test data is used in your measurements; do not use production data which can change
  • Tuning the file system is a matter of modifying only one or two parameters at a time with a gradual, minor adjustment; measure the impact of each change in order to monitor which parameters have the greatest effect
  • The following tools can be used to monitor NSS and measure performance:
    • Novell Remote Manager (NoRM)
    • NSS Commands NameCacheStats, CacheStats, Status and ZLSSIOStatus

  • Refer to the following documents:

  • There is no one-size-fits-all answer to optimising servers: each server's usage profile must be understood and parameters changed accordingly
Quick Wins
  • Use only NSS volumes on your server, not a combination of NSS volumes and NetWare Traditional volumes which will split resources
  • Split disk subsystems by function; e.g. do not put print queues or other temporary data (which will use bus bandwidth, constantly flush the cache and thrash the disk) on the same subsystem as user data
  • Turn off File Compression
  • Ensure that the best Host Bus Adapters (HBA) and Hard Disk Drives (HDD) available are in use as tuning cannot make up for slow components
  • Ensure the network is performing optimally: check with your network support
  • Ensure that as much memory as possible is in the server as memory is used for caching and buffering
  • Ensure that the latest firmware and drivers are in use as hardware manufacturers can make undocumented performance improvements
  • Some HBAs have on-board memory that can be tuned for read vs write caching or fault tolerance (e.g. immediate flush): check with your hardware vendor
  • Some HBA drivers have only one write queue per LUN thus striping data across a number of LUNs can dramatically improve performance: check with your hardware vendor
  • The load order (in STARTUP.NCF) of the HBA driver, Multiprocessor (PSM) driver and multipathing drivers can affect performance: check with your hardware vendor
  • Early drivers use a 63 sectors-per-track arrangement against HDDs that use 64 sectors-per-track thus forcing two read/write operations per read/write; ensure disks are partitioned using SCSIHD.CDM v3.1.4 dated August 2003 or later (therefore this is most likely to affect older disk subsystems that were partitioned before this module was applied). Note that any disk with a DOS partition will default to 63 sectors-per-track.
  • Turn off hyper-threading
  • Use NoRM to check whether the following parameters need to be increased as a shortage will impact performance:
    • Minimum Packet Receive Buffers
    • Maximum Packet Receive Buffers
    • Minimum Service Processes
    • Maximum Service Processes

  • Enable Opportunistic Locking/Client File Caching if appropriate

Additional Information

Use the Feedback link on this TID to suggest further tips for improving write performance. The best ones may be included in future revisions.