NetWare is a self-tuning operating system; however, there are some things you can do to adjust the server's memory subsystem (as well as other aspects of server operation) to fine tune its performance.
Before attempting to tune a new server's memory, let the server operate at full capacity for a week or two to allow NetWare to self-tune. After the server settles in to a predictable pattern of daily use, you can begin to fine-tune the server's memory as described in the following sections.
File cache not only speeds access to file data, it is used to cache portions of the Novell eDirectoryTM database. If you want to tune your NetWare server in general, or eDirectory in particular, tune the file cache.
In NetWare 6, the Novell Storage ServicesTM (NSS) is loaded on the server by default, but cache memory is not allocated to it unless it is actually running. NSS uses memory differently that the traditional file system and you must use specific parameters for tuning your server when using NSS.
To view statistics for cache buffers used by NSS, enter the following command at the System Console prompt:
nss /cachestats
For heavy access on an NSS logical volume, the server might incur some performance issues. NSS has its own caching and parameters to be set during the loading of the NSS modules. The following are several SET parameters that you can use to tune the performance of NSS:
Cachebalance controls how much memory is available for NSS to use for cache. The cachebalance percentage determines how many cache blocks NSS will take from the traditional file system for its own cache. A high cache balance percentage will impede the performance of the traditional file system. A low cache balance will impede the preformance of NSS. We recommend that you set the cache balance parmeter to equal the percentage of the total disk space you allocate for NSS. The default is 60 percent. If you are using mostly NSS volumes, you can run at a much higher percentage, such as 85 to 90 percent.
Closefilecachesize dictates how many closed files are kept in cache. The recommended minimum is 50,000.
Fileflushtimer and Bufferflushtimer Increasing these parameters from their defaults helps the caching up to a certain point, but too much increase causes a throttling problem with writing out the metadata. This is somewhat dependent on processor speed and disk speed, so you could try adjusting them for your system. If NSS performance is very poor, 75 might be too high and you could try 50. If performance is just below normal, you could try increasing the values a little.
To activate these parameters, you can issue the following command at the startup of NSS, or place it in the AUTOEXEC.NCF file:
nss /cachebalance=80 /fileflushtimer=75 /bufferflushtimer=75
/closedfilecachesize=50000
For more information on setting Cache Buffers for NSS, see Setting the Cache Buffers in the Novell Storage Services Administration Guide.
Because it is much faster to get data from memory than to get it from disk, caching frequently requested data increases server performance. The more RAM installed in the server, the more cache memory is available. Cache hits occur when a client requests data and the server supplies the data from cache memory instead of from disk. The least recently used algorithm determines whether data is kept in cache memory or written to disk.
File cache buffers are organized into a linked list. Most recently used (MRU) buffers are at the head of the list and least recently used (LRU) buffers are at the tail of the list. The length of time the oldest buffer has been in the list is shown as the LRU Sitting Time statistic.
In tuning file cache for the traditional file system, the goal is to determine how much memory the server needs so that recently accessed data can always be retrieved from cache. Monitoring the LRU Sitting Time statistic is key to tuning file cache.
The LRU Sitting Time status is updated and displayed once per second. The statistic is calculated by taking the difference between the current time and the time stamp of the last block in the cache list. (The time stamp is the time at which the last block entered the list.) The result is displayed in HH:MM:SS.0 format. The LRU Sitting Time measures the length of time it takes for a cache buffer at the head of the list to make its way down to the tail, where it becomes the least recently used (LRU) buffer. Every cache buffer in the list is being reused within that period of time.
In configurations with excessive cache, the LRU Sitting Time can be very high, even many hours. In configurations with too little cache, the LRU Sitting Time can be measured in seconds. The time can vary widely, depending on circumstances.
On inactive servers, such as those sitting unused overnight or those in lab environments with long periods of idle time, the LRU Sitting Time statistic is incremented by one second every second. This is because the LRU Sitting Time indicates the age of the LRU cache buffer. The LRU Sitting Time statistic is useless under these circumstances, except to confirm the obvious: that new data is not being written to the server's cache. This statistic is most useful during peak workloads when the server's cache is servicing the greatest number of users and the broadest possible data set.
You can view the LRU Sitting Time statistic using NetWare Remote Manager or MONITOR.
In NetWare Remote Manager, do the following:
Click the View Memory Config link in the navigation frame.
Click the Traditional File System Cache Statistics link on the System Memory Information page.
In MONITOR, from the Available Options menu, select Disk Cache Utilization.
To determine how much file cache your server needs, do the following:
Track server resource utilization statistics. Chart the results for daily, weekly, monthly, period-end, and year-end cycles. Identify recurring periods of peak workloads.
Observe the LRU Sitting Time statistic during peak workload periods of the day. Keep a record of the lowest LRU Sitting Time during the peak periods for at least one week, longer if necessary, to see a consistent pattern.
Based on the observations you made of the server's resource utilization and LRU Sitting Time, determine an average low LRU Sitting Time.
Tune the cache. Size the cache in such a way that the server can sustain an average low LRU Sitting Time of at least 12 minutes during peak workloads.
For example, if your server's original average low LRU was 7 minutes, you will need to add enough memory to increase the LRU Sitting Time to an average low of 12 minutes during peak workloads. This added memory increases the likelihood that repeatedly used data will still be cached when the next user request is received.
On the other hand, if the server's original lowest LRU sitting time was 18 minutes, the server has more than adequate cache. You can leave the excess memory in the server for future growth or remove it and use it somewhere else.
You can control when the server alerts you to serious decreases in the number of available file cache buffers. Use the following SET parameters (Traditional File System category).
Minimum File Cache Buffers establishes the minimum number of buffers that will always be reserved for file cache and not made available for other processes. When this minimum is reached, the server displays the message Cache memory allocator exceeded minimum.
Minimum File Cache Report Threshold instructs the server to send an alert before the minimum number of file cache buffers is reached. Set this parameter to the number of buffers above the minimum at which you want the server to send an alert. For example, if the Minimum File Cache Buffers value is 20 and the Minimum File Cache Report Threshold value is 30, the server sends an alert when 50 file cache buffers are left.
If you suspect that your server is slow in accessing eDirectoryTM, see Improving eDirectory Performance in the Novell eDirectory 8.6 Administration Guide.
The information for tuning directory cache applies only to NetWare servers using the traditional NetWare file system. Directory cache is not used by the Novell Storage ServicesTM (NSS) file system.
As directory entries are read and operated upon by a user, NetWare caches the entries to make repeated use of an entry more efficient. In a default configuration, NetWare allocates 20 cache buffers of 4 KB each. Each block read into a cache buffer contains 32 entries.
The default number of buffers is appropriate for only a small number of users. The tuning strategies in this section can help you tune the directory cache to meet your network's requirements.
Sizing the directory cache depends largely on the characteristics of the workload the server supports. The key is the frequency and breadth of directory searches, file opens, closes, and creations.
To handle low memory use, you probably won't need to allocate any more cache than the NetWare default. By default, NetWare allocates 20 buffers immediately upon request, followed by a maximum allocation of up to 500 buffers (about 2 MB). This is sufficient for the majority of low-use scenarios.
To tune for very high use, change the following SET parameters to the values shown using NetWare Remote Manager, MONITOR, or SET commands at the System Console prompt.
MINIMUM DIRECTORY CACHE BUFFERS = 2000
MAXIMUM DIRECTORY CACHE BUFFERS = 4000
In NetWare Remote Manager, click the Set Parameters link in the navigation frame, click the Traditional File System category link, click the parameter value link that you want to change, enter the new value, and click OK.
In MONITOR, from the Available Options menu, select Server Parameters > Traditional File System, select the parameter you want to change, type the new value, and press Enter.
When a name space is installed on a traditional NetWare volume, the volume's Directory Entry Table (DET) must include an additional directory entry for each file. So, for example, if a volume supports DOS, NFS, and LONG name spaces, there are three directory entries in the DET for each file instead of just one.
In such a case, a directory cache buffer with 32 directory entries no longer represents 32 files, it represents only 10 files, because each file now requires three directory entries.
This means the efficiency of your directory cache is decreased by a factor equal to the number of name spaces loaded. Therefore, you might need to add more memory if you load multiple name spaces. By carefully tuning the directory cache, you can maintain high performance even under these conditions.
Before adding name spaces, allow your server to operate in its production environment for several weeks. This lets NetWare allocate the appropriate number of directory cache buffers for the native DOS environment.
After this settling-in period, check the Directory Cache Buffer value in the MONITOR General Information window. This is the highest number of directory cache buffers allocated since the server was last started.
Use the following formulas to determine the optimum minimum and maximum number of directory cache buffers.
(# of names spaces, including DOS) x highest number of Directory Cache buffers since server was last started = minimum cache buffers
(minimum cache buffers) + 100 = maximum cache buffers
For example, if your server's highest number of Directory Cache buffers since server was last started is 250, and you want to load one additional name space, you would calculate the minimum and maximum values of directory cache buffers as follows:
2 x 250 = 500
500 + 100 = 600
Before loading the additional name space, change the following SET parameter values using NetWare Remote Manager, MONITOR, or SET commands at the System Console prompt:
MINIMUM DIRECTORY CACHE BUFFERS
MAXIMUM DIRECTORY CACHE BUFFERS
These settings increase the likelihood that repeatedly used directory cache buffers will remain in cache and that those buffers will remain in cache longer, providing the best possible read response times.
After you tune the directory cache, let the server operate for a few weeks to settle in. Then check to see whether the server allocates the additional directory cache buffers that the new settings allow. If the allocated buffers do not increase to near the level allowed, then you know that your users' directory access patterns don't require the additional cache. On the other hand, if your server uses all the cache you made available, your user community's directory access patterns might be more intensive than you anticipated.