z/OS Network File System Guide and Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


NFS client system performance tuning

z/OS Network File System Guide and Reference
SC23-6883-00

Table 1 contains NFS client system performance tuning symptom and action information.

Table 1. NFS client system performance tuning symptom and action information
Symptom Action
Excessive NFS retransmissions A high number of NFS retransmissions can be detected with the nfsstat -c command. See section Impact of the NFS protocol on performance for more information. A general rule of thumb is that the number of retransmissions should not be more than 2% of the total calls. Use traceroute hostname command to trace the route that IP packets take to a network host. This helps isolate where the bottleneck may occur.
Symptom Action
  ACTION 1: Increase network queue length - If the nfsstat -c command shows evidence of bad calls in addition to timeouts, or the netstat -s indicates that packets or fragments are being dropped, increasing the network queue length may be advisable. Occasionally, a network analyzer will detect that the server has responded to an NFS request before the client retransmits the request. This indicates that the network queue on the NFS client system was full and the response was dropped.

ACTION 2: Increase maximum transmission unit - The nfsstat -in command will display the maximum transmission unit (MTU) for each network interface active on the NFS client system. The MTU can be reset with the ifconfig command. This command is available on most UNIX NFS clients. For the z/OS NFS client, MTU can be reset in the TCP/IP profile. Increasing the MTU can improve overall performance and alleviate excessive IP fragmentation. However, with heterogeneous networks the MTU should not be set larger than the smallest acceptable MTU over the entire network route. For instance, when the network consists of a mix of Token Rings and Ethernets, the MTU is typically set at 1492 that is less than the 1500 MTU for an Ethernet and a 2000 MTU for Token Ring. Changing the network topology may allow you to increase the NFS client system MTU.

ACTION 3: Change socket buffer size - Changing the buffer size is another way to tune the NFS client system. The AIX no -a command will display the current settings, in particular the udp_sendspace and udp_recvspace. The AIX no -o udp_sendspace=32768 and no -o udp_recvspace=32768 commands can be used to reset the udp_sendspace and udp_recvspace, respectively. For the z/OS NFS client, the udpsendbfrsize and udprecvbfrsize in the TCP/IP profile should be set respectively. The recommended value for Sun NFS V3 protocol is 65536. When processing with TCP protocol, it may be necessary to modify the tcpsendbfrsize and tcprecvbfrsize.

ACTION 4: Increase number of BIODs - If data on an NFS server is typically accessed sequentially, or if there are many users on an NFS client system, it may be advantageous to increase the number of block I/O daemons (BIODs). This increases the NFS client processor utilization and should be weighed against other processor requirements on a multiple user system. If access is typically at random offsets within a file or file sizes are very small, you may even consider decreasing the number of BIODs. It should also be noted that some NFS client implementations honor BIODs differently to provide read or write bias.

ACTION 5: Increase timeout parameters - If you have determined that NFS retransmissions are not caused by dropped NFS responses, you may consider increasing the timeout value. This should be one of the last alternatives you select since this can have adverse effects. If information is lost or dropped between the NFS client and the NFS server, increasing the timeout value can make performance worse. In this case the client would wait longer to decide to resend a request. In a heavily used NFS environment, increasing the timeout value also increases the likelihood that internal client or server buffers will become stagnant or stolen to service other network requests. You would probably only want to attempt this if you have strong evidence, probably from a network analyzer, that the NFS server is sending responses after the NFS client retransmits requests. The timeout values can be reset with the mount command.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014