2.2 biod daemons on clients

Client tuning is a bit more difficult (interesting?) than the server :) One thing you can fairly easily tune are the biod (daemons) on the client nodes.

On the clients, biod are the daemons that handle block IO. They help read-ahead and write-behind on remote file systems in order to improve performance. You can actually run without any biod is you want and you can still use NFS. But running them allows you to possibly improve IO performance on the clients.

One [1] below discusses biod's on the clients. The link is for SCO, but the general concepts are applicable to Linux. From the link,

On an NFS client system, you do not need to run any biod processes for applications to access remote filesystems. The biods handle read-ahead and write-behind on remote filesystems in order to improve performance. When reading, they send requests to read disk blocks ahead of that currently requested. When writing, they take over responsibility for handling writing the block to the remote disk from the application. The biod processes visible using ps(C) are merely convenient handles used by the process scheduler to control NFS client operation -- the majority of the work dealing with the read and write requests is dealt with inside the kernel.

If no biods are running, the application's performance will suffer as a result. When it writes to the remote filesystem, the write system call will block until the data has been written to the disk on the server. When it reads from the remote filesystem, it is unlikely to find the blocks in the buffer cache.

From this, you might deduce that running an extra copy of biod will always enhance NFS performance on the client. For example, if four biods are running, each of these can perform asynchronous writes without applications programs having to wait for these to complete. If an application requires access to the remote filesystem while the biods are busy, it performs this itself. The limit to performance enhancement comes from the fact that each biod's disk requests impose a load on the server. nfsd daemons, the buffer cache, and disk I/O on the server will all come under more pressure if more biod daemons are run on the clients. Network traffic will also increase as will the activity of the networking protocol stacks on both the server and its clients. The default number of biod processes run on a client is four. To see if the number running on your system is adequate, use the ps -ef command and examine the elapsed CPU time used by the biods under the TIME column. Note that the results are only meaningful if your system has been operating under normal conditions for several hours.

If nfsstat -c on the client shows a wait for client handle value of zero and if the TIME value for at least one of the biods is substantially less than the others, then there are probably enough daemons running. If several biods show low TIME values, it should be safe to reduce their number to one more than the number showing high TIME values.

If all the TIME values are high, increase the number of biods by two, and continue to monitor the situation.

If you are root, you can reduce the number of biods running by killing them with kill(C). You can also start extra biods running using the command /etc/biod.

To change the number of biods that are configured to run, edit the following lines in the file /etc/nfs on each client:

  [ -x /etc/biod ] && {
          echo " biod(xnumber)\c"
          biod number &
  }

When NFS is next started on the client, number biods will run.

The procedure above can be a little complicated, but try to follow the steps (ask questions if you need to). In addition, don't forget to use your applications if possible so that you can get a better understanding of the impact of biod's on your application performance.