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.
|