NetWare 4.x Performance Tuning and Optimization: Part 3
Articles and Tips: article
Senior Consultant
Systems Research Department
01 Oct 1993
This AppNote provides a list of miscellaneous SET parameters in NetWare 4.x that may be tuned to specific server resource utilization trends and workload patterns to improve performance.
Part 1 of this series outlined the performance enhancements included in NetWare 4.x. Part 2 described NetWare's auto-tuning capabilities and related SET parameters.
Previous AppNotes in This Series May 93 "NetWare 4.0 Performance Tuning and Optimization: Part 1 Jun 93 "NetWare 4.0 Performance Tuning and Optimization: Part 2 Mar 93 "Using Production Workload Characteristics to Validate LAN Performance Evaluation Studies" May 92 "Identifying Test Workloads in LAN Performance Evaluation Studies"
Tuning Miscellaneous SET Parameters
Customers often ask Novell for a list of recommended SET parameters to enhance the performance of a NetWare server. However, considering the variety of situations when you need to either (a) determine whether your network is completely tuned and optimized, or (b) raise your network's level of performance to a new high, it's not always obvious where to start. NetWare's SET parameters are only one of your options.
If we were to list the tuning and optimization options available to you, that list would definitely include a variety of software tuning optionsCof which the SET parameters are a subset. But it would also include two other categories of options: process and data architecture optimizations (load balancing) and hardware optimizations.
Aside from the SET parameters that affect NetWare's auto-tuning capabilities, these latter two categories are much more capable of contributing to increased levels of performance. This is primarily due to the general appropriateness of NetWare's off-the-shelf SET parameter defaults and to the fact that network workloads usually bottleneck on hardware components before software constraints come into play.
Important: Take care as you consider making changes to NetWare's SET parameter defaults. Changes require well-founded justification rather than hit-or-miss guesswork because, if misused, the SET parameters provide more capacity to hurt performance than to improve it.
Of over 125 NetWare 4.x SET parameters, we chose the following nine due to their potential capacity to influence performance in some systems. Other SET parameters that influence NetWare's auto-tuning capabilities are discussed in a prior AppNote (see "NetWare 4.0 Tuning and Optimization: Part 2" in the June 1993 NetWare Application Notes).
File Caching SET Parameters
The SET parameters discussed in this section pertain to NetWare's file or disk caching. Requests from workstations can be serviced up to 100 times faster when data is read from and written to the server's cache memory, rather than going directly to the hard disk.
Maximum Concurrent Disk Cache Writes. This SET parameter allows you to regulate the flow of disk cache writes through the disk channel. A disk cache write is a write request (or a suballocated block of multiple write requests) that the server passes through the disk channel. Each write request is stored in server cache awaiting an opportunity to be written to the physical storage medium.
The syntax for this parameter is as follows:
|
SET parameter = default setting |
min .. max |
|
Set maximum concurrent disk cache writes = 50 |
10 .. 4000 |
In NetWare 3.x, the disk elevator (which tracks readied disk cache writes) provides no prioritization of reads over writes. During intense write operations involving many megabytes of data, read requests could be delayed long enough to be noticed by users. In NetWare 3.x environments where intense write processes are a frequent occurrence, you may choose to "starve" the disk by lowering the number of concurrent disk cache writes to a point where read requests have a greater probability of being serviced fairly.
In NetWare 4.x, a new disk write prioritization scheme has been developed to overcome this problem. This tiered prioritization of the disk elevator reduces the possibility of ignored reads and supports lower priorities for read-ahead requests. (For more information, refer to "NetWare 4.0 Tuning and Optimization: Part 1" in the May 1993 NetWare Application Notes.)
Another use of this SET parameter, which applies to both NetWare 3.x and 4.x, has to do with large disk arrays that have the capacity to handle hundreds of disk requests at once. In these cases, the default can actually starve the disk channel unnecessarily. You may want to increase the maximum to more fully utilize the capacity of these types of subsystems.
The maximum setting of this SET parameter was increased to 4000 to accommodate disk channels with many spindles. For example, a channel with 30 drives could process several thousand requests per second. That same configuration would starve under the current default number of maximum concurrent disk cache writes.
Dirty Disk Cache Delay Time. This SET parameter decreases the probability of redundant writes to disk. When a NetWare server receives a write request, the requested operation is written to cache in the form of an addition, a deletion, or a modification to an existing block of data. This cache buffer containing data that is different from the corresponding block on disk is referred to as a "dirty" cache buffer.
NetWare could perform an immediate write of these "dirty" buffers to disk, but that would create a 1:1 ratio of physical writes to write requests. By waiting the time specified by this SET parameter, NetWare increases the probability that a subsequent write request will impact the same block and allow NetWare to satisfy two write requests with one physical write. Of course, the benefits of this scenario depend on the number of intra-block writes encountered before the delay time expires.
The syntax for this parameter is as follows:
|
SET parameter = default setting |
min .. max |
|
Set dirty disk cache delay time = 3.3 |
0.1 .. 10 sec |
If your system has cache to spare, and your workload includes a high number of sequential write operations, you may realize some benefit by increasing this delay time.
Directory Caching SET Parameters
The SET parameters discussed in this section deal with NetWare's directory caching. Directory caching is similar to file caching, only it is the File Allocation Table (FAT) and directory entries that are held in server memory. The server can find a file's location from the directory cache much faster than retrieving the information from disk, thus increasing disk access performance.
As explained in "NetWare 4.0 Performance Tuning and Optimization: Part 2" in the June 1993 issue, many NetWare servers now support very large directory spaces containing hundreds of thousands of files. In these cases, it is impractical to cache all of the directory entries in server RAM. Thus NetWare 3.x and 4.x allocate less cache for directory entries and use a least-recently-used (LRU) algorithm to discard unused directory cache blocks to make room for newly read or written blocks of data.
Maximum Concurrent Directory Cache Writes. This SET parameter allows you to regulate the flow of directory cache writes through the disk channel. A directory cache write is created with each directory addition, deletion, or modification that the server passes through the disk channel.
The syntax for this parameter is as follows:
|
SET parameter = default setting |
min .. max |
|
Set maximum concurrent directory cachewrites = 10 |
5 .. 50 |
If your system has a large directory cache (as recommended in Part 2 for servers with hundreds of thousands of frequently-accessed, small files), and your disk subsystem is capable of handling a high rate of requests per second, you may realize some benefit by increasing this maximum. The rate of requests that a particular disk subsystem can handle is a function of (1) the disk speed, (2) the number of spindles making up the logical drive, as in an array or spanned volume, and (3) the pattern - random or sequential - of the workload.
Directory Cache Buffer Nonreferenced Delay. This SET parameter specifies the length of time a directory cache buffer must go unreferenced before it becomes a candidate for dismissal. If all directory cache buffers are referenced within this delay time, a new directory cache buffer is allocated using the directory cache allocation wait time.
|
SET parameter = default setting |
min .. max |
|
Set directory cache buffer nonreferenceddelay = 5.5 |
1 .. 300 sec |
This SET parameter has less impact on performance if the directory cache is appropriately sized to the workload characteristics of the directory's user community. For this reason, we don't recommend any changes to this parameter.
Dirty Directory Cache Delay Time. This SET parameter reduces the probability of redundant directory cache writes. When a directory request (write) is received by a NetWare server, the requested operation is written to cache in the form of an addition, a deletion, or a modification to an existing directory cache block.
If NetWare performed an immediate write of the directory cache block to disk, that would create a 1:1 ratio of physical writes to write requests. By waiting the time specified by this SET parameter, NetWare increases the probability that a subsequent change to the directory will alter the same block and allow NetWare to satisfy multiple requests with one physical write.
|
SET parameter = default setting |
min .. max |
|
Set dirty directory cache delay time = 0.5 |
0 .. 10 sec |
If your system has a large directory cache (as recommended in Part 2 for servers with hundreds of thousands of frequently-accessed, small files), you may realize some benefit by increasing this delay time.
File System SET Parameters
The SET parameters discussed in this section pertain to two features of NetWare's file system: the salvagability of deleted files, and read-after-write verification.
Immediate Purge of Deleted Files. This SET parameter turns NetWare's salvageable file system on or off. When this parameter is set to OFF (the default setting), the salvageable file system uses excess disk space to store deleted files indefinitely. This system's merits can be stated simply. You can recover files that are deleted by mistake hours, days, even weeks after the accident. Many customers have, and will in the future, rely on this life-saving feature. The performance trade-off is the system overhead required to keep track of deleted files.
|
SET parameter = default setting |
Options |
|
Set immediate purge of deleted files = OFF |
ON |
We recommend that everyone leave the salvageable file system in place to protect against mistakes.
Important: To leave the salvageable file system enabled, keep this parameter at its default setting of OFF.
If you perform nightly backups and have adequate access to that data, you may choose to purge all deleted files after your backup routine. This can be done using the NetWare FILER utility.
Enable Disk Read After Write Verify. With the introduction of network file servers in the early 1980s, the designers of NetWare recognized the increased need for system reliability and data integrity if disk storage is to be shared by multiple users. The idea of losing data belonging to a group was perhaps a bit more compelling than losing just one person's data on a private hard disk.
Read-after-write verification (RAWV) is the process NetWare uses to verify the success of every write request, thereby guaranteeing the integrity of stored data. Each sector of data that is written to disk is read back from disk and compared to the original data in the server's memory. If the data read from disk is identical to the data originally written, the RAWV is successful. If not, NetWare assumes there is a potential media failure. In that event, the data is written to a different area on the disk. Another NetWare feature called Hot Fix is activated to redirect the pointers to the bad block to a good block in the Hot Fix area of the disk.
Prior to Netware 2.1, it was unusual to find off-the-shelf disk subsystems with RAWV provided at the hardware level. That is why Novell engineers implemented RAWV in the NetWare disk process and disk drivers. The introduction of linkable disk drivers in NetWare 2.1 and loadable drivers in NetWare 3.x and above allowed third party drive manufacturers to provide specialized drivers for their disk subsystems. Since third parties have handled the development of most drivers, RAWV has become the driver developer's responsibility.
Both driver and hardware technology have improved greatly since the early 1980s. What used to be handled by NetWare at the operating system level can now be done much more efficiently at the hardware level, closer to the physical drive. Consequently, NetWare 3.x and 4.x support three levels of RAWV:
Hardware Level (verification performed at the firmware level)
Software Level (verification performed by the driver)
Disabled
In both NetWare 3.x and 4.x, the driver reports back to NetWare what level of RAWV it is performing at load time. Currently, most drivers default to hardware-level verification. To check your driver's RAWV level, use the MONITOR utility. Select "Disk Information" at the main menu, then select the disk drive. You'll see a drive status screen for that drive which displays the RAWV level being provided by your disk driver (see Figure 1).
Figure 1: MONITOR's display of the Read-After-Write Verification level for a NetWare disk driver.
If MONITOR reports hardware level verification, this is the most efficient of the two verification levels and you should leave it alone.
If MONITOR reports software level verification, you may be able to change to the more efficient hardware level verification (check with your disk driver developer). If you can, see if the driver has a command line parameter to specify hardware level verification during load time. If not, the change can only be made in MONITOR, each time the driver is loaded.
If MONITOR reports that RAWV is disabled, either the driver is not performing RAWV or it may be performing some other type of verification (find out from your driver developer).
The SET parameter "Enable Disk Read After Write Verify=" does nothing more than set a global variable available to the disk driver. However, most drivers don't check the variable dynamically. So although this parameter defaults to ON, most drivers may ignore the setting altogether.
|
SET parameter = default setting |
Options |
|
Set enable disk read after write verify = ON |
OFF |
This is one case where reliability takes precedence over performance. Always use NetWare with read-after-write verification enabled, even during benchmarks.
NCP SET Parameters
NCP Packet Signature Option. NCP packet signature is an optional NetWare security feature that appends a unique signature to each NCP packet sent between NetWare client and server. This SET parameter turns packet signing on or off. When turned on, the parameter setting also designates this feature's level of enforcement.
|
SET parameter = default setting |
Options |
|
Set NCP packet signature option = 1 |
0, 1, 2, 3 |
Packet signing is recommended for systems that require this high level of security. When enabled at the server, this feature must also be enabled on participating clients via the SIGNATURE LEVEL= setting in the NET.CFG file. (Refer to the NetWare documentation for an explanation of each level.)
In production environments, packet signing can have a significant impact on performance because of the 400 additional instructions necessary to sign or validate individual NCP packets. Three events in the normal day-to-day operations are affected:
During login, signing-enabled clients negotiate a session key with the server.
Every packet transmitted is signed.
Every packet received is validated.
The packet signing overhead added to the login process is trivial for most environments because the login process occurs so infrequently. However, the overhead during the transmittal and reception of each packet can be significant.
For more information on packet signing and our detailed performance recommendations, see "NCP Packet Signature Performance Considerations" in the December 1992 NetWare Application Notes.
Enable IPX Checksums. A checksum is a simple error detection method that computes the sum of bits making up the data being transmitted from one computer to another. Once computed, the checksum process is repeated at the other end of the conversation and compared with the original value for accuracy. This SET parameter allows you to turn IPX checkums on or off.
|
SET parameter = default setting |
Options |
|
Set enable IPX checksums = 1 |
0, 1, 2 |
In the NetWare paradigm, data corruption that occurs over a transmission medium (a LAN or WAN connection) is caught and corrected by link-layer protocols on both ends of the connection. IPX checksums are not necessary for this traditional level of NetWare reliability. The NetWare IPX checksum feature is available to those who want to catch data corruption that may occur during data transmission between the LAN driver and the NetWare operating system via the internal system bus. Although the likelihood of internal data corruption is remote, this feature is available to third-party developers in the IPX API as a session-level error detection method for applications that require the extra protection.
For systems that require this high level of data integrity, IPX checksums are recommended. When enabled at the server, this feature must also be enabled on participating clients.
However, we do not recommend the use of this feature generally due to the significant performance hit of checksum processing, without significant justification.
Note: The IPX checksum feature is not supported by the Ethernet 802.3 frame type. For more information about Ethernet frame types, see "Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2" in the September 1993 NetWare Application Notes.
Summary
This AppNote has covered NetWare 4.x SET parameters related to file and directory caching, the file system, and NCP enhancements. Part 4 of this series will discuss NetWare 4.x server memory.
* Originally published in Novell AppNotes
Disclaimer
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.