DIGITAL TCP/IP Services for OpenVMS
Management

1. The summary of CFS services indicates the distribution of the CFS services. The OTHER category includes MAP, EXPORT, IMPORT, OPERATOR, STATUS, TRANSLATE, and UNMAP services.
2. The summary of OpenVMS system services indicates the consumption of various system services. Each service used by CFS is tallied with the addition of the subtotals for the $QIO system service. These totals are indicators of the XQP and disk performance.

The SHOW CFS/SUMMARY command provides a good indication of file system performance at the moment by providing the current and maximum values. See the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual for a description of the SHOW CFS/SUMMARY command.

Example 16-2 shows a file summary that is displayed after entering the SHOW CFS/SUMMARY command. The numbers in the example are keyed to the discussion that follows.

Example 16-2 SHOW CFS/SUMMARY Display

TCPIP> SHOW CFS /SUMMARY CFS Service status and performance 21-MAR-1997 10:36:05.82 (1) (2) Service State Cur Max Total Cacheop Cur Hit I/O Inc Status --------------- --- --- --------- ------- ---- ---- ---- ---- ------------ FP-Access 0 1 374 Read 0 0 0 0 Clusize 16 FP-Attributes 0 1 2246 Read-A 0 0 0 0 Limit 256 FP-Delete 0 0 0 Write 0 0 0 0 Inuse 0 FP-Dir 0 1 989 Write-A 0 0 0 0 Busy 0 FP-Rename 0 0 0 Write-D 0 Hitrate 0 FP Sub_total 0 2 3609 (3) Buffered 0 0 0 Nameop Cur Hit Status Internal 0 1 127 ------ ---- ---- ------------- I/O 0 1 11 Add 0 Tabsize 0 Lock 0 3 73 Delete 0 Inuse 0 Logging 0 0 0 Lookup 0 0 Hitrate 0 Resource 0 0 0 (4) RMS 0 0 0 Fileop Cur Hit Status Service 0 1 1 ------ ---- ---- ------------- Timer 0 1 1179 Find 0 0 Limit 0 Other 0 0 0 Find-A 0 Inuse 0 Synch 0 1 994 Find-C 0 Timeout 5 Hitrate 0 (5) Services count 1 4 2863 ATCBs:4 TBABs:32 RDCBs:260 Pages:34(6)

1. The service state indicates the reason that a thread goes into a wait state. By determining where most of the waits occur, you can determine what in the system is slowing down the server.
2. The summary of data cache performance indicates how the file system cache is performing. This summary provides the current set of parameters:
   • Cluster size
   • Cache size limit (logical name TCPIP$CFS_CACHE_SIZE, defined in the NFS server startup file SYS$STARTUP:TCPIP$NFS_SERVER_STARTUP.COM.)
   • How much of the cache is in use
   • How many I/O requests are outstanding
   • Overall hit rate of the cache
   
   All these values are related to cluster size (CLUSIZE) buffers. These buffers show the maximum number of blocks that can be read from or written to a disk.
   The read and write groups are synchronous, while Read-A and Write-A groups are asynchronous. The Write-D group is a deferred write operation, where the caller unmaps data without writing to disk. A UNIX style file system frequently uses the Write-D group.
3. The summary of name cache performance provides the number of lookup operations saved by the name cache. The name cache converts a file-handle/name pair into another file handle, which saves lookup operations, because each entry found in the cache (a hit) saves a lookup operation.
4. The summary of file-attributes cache indicates how the attributes (file RDCB) cache is performing. The file-attributes cache values are described in Table 16-4.

   Table 16-4 File-Attributes Cache Values

   Value	Description
   Limit	Maximum number of resource descriptors and control blocks (RDCBs) that can be in cached status at any moment
   Inuse	Number of RDCBs in use
   Timeout	Number of seconds that any cached file's atributes are considered valid
   Hit rate	Number of XQP QIOs (read attributes) that were saved because the valid RDCB was found (other overhead is also saved, for example, $ENQ/$DEQ time)

5. The summary of services and resources allocated provides the number of services and varying control blocks that are allocated. These services may not correspond one-for-one to NFS services because one service can call another to perform a special function. This is particularly true for container file systems, which make internal calls to certain operations in the OpenVMS space.
   The services and resources allocation values are described in Table 16-5.

   Table 16-5 Services and Resources Allocation Values

   Value	Description
   ATCBs	Asynchronous thread control blocks (one per thread)
   TBABs	Thread backout attachment blocks (one per active virtual lock)
   RDCBs	Resource description and control blocks (one per node, one per file system, one per file, one per cache buffer)
   Hit rate	Number of XQP QIOs (read attributes) that were saved because the valid RDCB was found (other overhead is also saved, for example, $ENQ/$DEQ time)

6. The pages from the virtual address space that are used dynamically when 512 bytes or less are needed for scratch space. A page also provides space for the record mapping table entries needed when accessing nonstream sequential files (record format conversion).

Because the NFS server does not maintain state about any of its clients, clients do not send explicit open and close file requests to the server. Instead, the server opens and closes the files for the clients. Any read or write request causes the server to open the file (if it does not already have the file open). The server caches the open files to create an internal state for each file within the NFS server environment.

The server uses the following guidelines to close the files:

• Closes the files that were not accessed during the specified time interval
• Closes the oldest files when a user wants to access a new file and the maximum number of opened files for the NFS process or the maximum number of opened files specified in the OpenVMS account is reached.

A short interval may cause the server to close files more often, thereby reducing performance. The default interval is 2 minutes. You can control the time interval by setting a new value for the TCPIP$NFS00000000_INACTIVITY logical name or by using the /INACTIVITY_TIMER qualifier of the SET NFS SERVER command.

16.13.4 Increasing the Number of Active Threads

The NFS server is an asynchronous, multithreaded process, which means that multiple NFS requests can be processed concurrently. Each NFS request is referred to as a thread. With increased server activity, client users may experience timeout conditions. Assuming the server host has the available resources (CPU, memory, and disk speed), you can improve server response by increasing the number of active threads. You do this by changing the value for the TCPIP$NFS00000000_THREADS logical name. Use the SHOW NFS_SERVER command to display the maximum number of active threads.

If you increase the number of active threads, you should also consider increasing the timeout period on UNIX clients. You do this with the timeo or /TIMEOUT option to the MOUNT command.

If your clients still experience timeout conditions after increasing the number of active threads and the timout period on the client, you may need higher-performing hardware.

16.13.5 Increasing the Size of the Host Table

During NFS initialization, the server builds a host table from the proxy database file. If the number of client hosts listed in the proxy database exceeds the number specified with the TCPIP$NFS00000000_HOST logical name, the excess client host names are ignored. This action disables access to the server for those client host names that cannot be loaded into the server's cache.

Making the parameter value larger than needed causes NFS to allocate excess virtual memory within the server.

16.13.6 Increasing the Size of the Transaction Cache

Because NFS uses UDP as an underlying protocol, delivery between the client and the server is not guaranteed. Because delivery is not guaranteed, the client often reissues an NFS request if it does not receive a response from the server within a certain time period. This may cause CREATE, DELETE, LINK, RENAME, SYMLINK, and SETATTR operations to successfully complete the first time but fail the second time with a false error.

Each server's response to a client request is identified by the host name and a transaction identifier (XID). The server stores the responses it makes to any client requests for directory and file access. This way, whenever a client request is recognized as a duplicate, the server checks the response cache to see if a response has been sent. If it finds a matching response, the response is resent; otherwise, the duplicate request is ignored.

If the the request is not a duplicate, the message is dispatched and processed.

The size of the cache for these operations is limited by the value set with the TCPIP$NFS00000000_XID logical name. The default is 20, but you should increase this value if you notice any of the following situations on a client:

• A file or link creation request returns "file exists," but the file did not exist when the file creation was requested and does exist after the file creation request.
• A file/directory or link deletion request returns "no such file," but the file did exist and does not exist after the deletion request.
• A rename request returns "no such file," but the file did exist under its old name when the rename operation was requested and exists under its new name after the rename request.
• A set attributes request returns "privilege violation," but the file can be written to by either the owner or group requester and does exist after the request with the new attributes.
• You increase the maximum number of threads.
• You have not altered the client's timeo option to at least 20 (2.0 seconds).

The NFS server supports access to XQP+, the extended QIO processor file system enhancements introduced in OpenVMS Version 6.1. The XQP+ features are described in detail in the OpenVMS Version 6.1 New Features Manual.

Performance improvements offered by XQP+ are especially beneficial for NFS servers that are handling a heavy load. By default, the XQP+ functionality is disabled; you must enable it by setting certain SYSGEN parameters.

The file SYS$STARTUP:TCPIP$NFS_SERVER_STARTUP.COM describes how to enable OpenVMS and TCPIP-level usage of XQP+ features. The file also describes how to define logical names in SYS$STARTUP:TCPIP$SYSTARTUP.COM so that the site-specific choices are preserved across NFS and OpenVMS upgrades.

The NFS server can take advantage of the following XQP+ features:

• Improved file system concurrency
  On a single system or in a cluster with all nodes running OpenVMS Version 6.1 or greater, you can enable XQP+ improved file system concurrency by setting the SYSGEN special parameter XQPCTL2 to 1 and then rebooting.
  As with all performance changes, make sure you understand the action of this configuration. For complete information about invoking the AUTOGEN command procedure to collect configuration information and rebooting your system, see the OpenVMS System Manager's Manual.
• XQP+ threads, applicable for ODS--2 disks only
  To enable XQP+ threads:
  1. Set the SYSGEN parameter XQPCTLD1 to a number greater than 1. Because only executable images that specifically enable additional XQP+ threads use additional resources, it is usually safe to set the number to 8. The system manager should determine the specific value for each configuration, because XQPCTLD1 is a dynamic system parameter that takes effect immediately.
  2. Define the logical name TCPIP$CFS_ACP_ENABLE_THREADS as follows:

     $ DEFINE/SYSTEM/EXECUTIVE_MODE TCPIP$CFS_ACP_ENABLE_THREADS 1

     
     The usual way to do this is to create, if necessary, the command procedure SYS$STARTUP:TCPIP$SYSTARTUP.COM, then edit the procedure appropriately.

  3. Shut down and restart the server for the change to take effect.
• Performance enhancement through a change in the process of writing data to files
  A write to a file on the OpenVMS operating system usually involves two operations: writing the actual data and updating the file header. When writes occur in rapid succession, it is possible to reduce the time taken to write the file by performing a series of data writes and then updating the file header once. The balancing risk is that information may be lost if the system crashes before the file header is updated.
  To cause the XQP to possibly defer file header writes, enter the following command:

  $ DEFINE/SYSTEM/EXEC TCPIP$CFS_ACP_ENABLE_DEFERRED_HEADER_WRITES 1

  
  Be aware that this command allows the NFS call to return without waiting for certain file header operations to complete. This behavior is a technical violation of the NFS protocol, but it is common practice for some NFS vendors. If the system crashes before the file header completes, the data is written but may be inaccessible. Enter the following command from a suitably privileged account to return the file to a consistent state to determine whether the Analyze/Disk_Structure utility repairs errors that are detected in the file structure of a specified device:

  $ ANALYZE/DISK_STRUCTURE/REPAIR device

  
  This XQP+ feature offers a performance increase at the risk of data loss. Compaq strongly recommends against enabling this feature until you determine that the risk of data loss is acceptable. After enabling this feature, shut down and then restart the NFS server for the change to take effect.

The NFS server is started by the auxiliary server using the NFS server account TCPIP$NFS, which includes the NFS server process quotas and resource limits.

You can increase the NFS server account quotas and limits to improve the performance of the NFS server. Use the OpenVMS Authorize utility to change the quotas and limits for the TCPIP$NFS account.

16.13.9 Increasing UAF File Limits

A file limit (FILLM) quota is associated with each OpenVMS user account. The FILLM quota specifies the maximum number of files that can be accessed simultaneously. If a file is accessed to process a read or write request, the file access cannot exceed the FILLM quota specified in the OpenVMS user's authorization information. To make this file limit transparent to the client, NFS closes the least recently accessed file and accesses the new file. When this happens, the error log file contains an "exceeded quota" message.

Because the open files quota information is loaded into the NFS server at startup, changes to a user's authorization information do not take effect until you restart the NFS server.

An FILLM quota is also associated with the NFS server account. If the FILLM quota is set too low, it degrades the server's performance. Set this quota so it is large enough to accommodate the total of all the individual NFS users' quotas.

Under normal situations, the NFS request is successfully completed after you reset the quota limitation. The inactivity timer interval can reduce the required open files quota by closing old files automatically before the contention.

You may have set up proxy mapping such that many incoming users map to one OpenVMS account, causing multiple users to share the same file quota. In such a case, ensure that the FILLM value for this account is large enough to provide satisfactory performance for all the users associated with this account.

The CHANNELCNT parameter sets the maximum number of channels that a process can use. Ensure that CHANNELCNT is set large enough to handle the total number of files accessed by all clients.

16.13.10 OpenVMS SYSGEN Parameters That Impact Performance

The following OpenVMS SYSGEN parameters impact NFS server performance:

• ACP parameters
  The NFS server issues a large number of ACP QIO calls through CFS. Altering certain ACP parameters could yield better performance. If you have reliable disks, you may want to set the parameter ACP_DATACHECK to 0 to avoid extra disk I/Os. Directory searching and file attribute management constitutes a majority of the ACP operations. Therefore, Compaq recommends that you increase parameters such as ACP_HDRCACHE, ACP_MAPCACHE, ACP_DIRCACHE, ACP_FIDCACHE, and ACP_DATACACHE.
• LOCK parameters
  The various lock manager parameters may need some alteration because CFS uses the lock manager extensively. A lock is created for each file system, each referenced file, and each data buffer that is loaded into the CFS cache.
• VIRTUALPAGECNT
  Maximum virtual size of a process in pages. The NFS server requires larger-than-normal amounts of virtual address space to accommodate structures and buffer space.
• WSMAX
  Maximum physical size of a process in pages. The larger the working set, the more pages of virtual memory that can remain resident. Larger values reduce page faults and increase the server's performance.