Chapter 2. Mount options 21
2.2 Tuning NFS client cache behavior
Other mount options allow you to tailor the client’s attribute caching and retry behavior. It is
not necessary to adjust these behaviors under most circumstances. However, sometimes you
must adjust NFS client behavior to make NFS appear to your applications more like a local
filesystem, or to improve performance for metadata-intensive workloads.
There are a few indirect ways to tune client-side caching. First, the most effective way to
improve client-side caching is to add more RAM to your clients. Linux will make appropriate
use of the new memory automatically. To determine how much RAM you need to add,
determine how large your active file set is and increase RAM accordingly. This greatly
reduces cache turnover rate. You should see fewer read requests and faster client response
time as a result.
Some working sets will never fit in a client’s RAM cache. Your clients may have 128MB or
4GB of RAM, for example, but you may still see significant client cache turnover. In this case,
cache miss latency is the best approach. You can do this by improving your network
infrastructure and tuning your server to improve its performance. Because a client-side cache
is not effective in these cases, you may find that keeping the client’s cache small is beneficial.
Normally, for each file in a filesystem that has been accessed recently, a client caches file
attribute information, such as a file’s last modification time (mtime) and size. To detect file
changes quickly yet efficiently, the NFS protocol uses
close-to-open cache semantics. When
a client opens a file, it uses a GETATTR operation to check that the file still exists and any
cached data it has is still up-to-date. A client checks back with the server only after a timeout
indicates that the file’s attributes may be stale. During such a check, if the server’s version of
the attributes has changed, the client purges its cache. A client can delay writes to a file
indefinitely. When a client closes a file, however, it flushes all pending modifications to the file
to the server. This allows a client to provide good performance in most cases, but means it
might take some time before an application running on one client sees changes made by
applications on other clients.
Clients should check back with the server every so often to be sure cached attribute
information is still valid. However, adding RAM on the client will not affect the rate at which the
client tries to revalidate parts of the directory structure it has already cached. No matter how
much of the directory structure is cached on the client, it must still validate what it knows
when files are opened or when attribute cache information expires. You can lengthen the
attribute cache timeout with the actimeo mount option to reduce the rate at which the client
tries to revalidate its attribute cache. With the 2.4.19 kernel release, you can also use the
nocto mount option to reduce the revalidation rate even further, at the expense of cache
coherency among multiple clients. The nocto mount option is appropriate for read-only mount
points where files change infrequently, such as a lib, include, or bin directory, static HTML
files, or image libraries. In combination with judicious settings of actimeo you can significantly
reduce the number of on-the-wire operations generated by your NFS clients. Be careful to test
this setting with your application to be sure that it will tolerate the delay before the NFS client
notices file changes made by other clients and fetches the new versions from the server.
Certain distributions also support an option that disables Access Control List support on
NFSv3 mounts. After update 3, RHEL 3 allows you to disable ACL support, eliminating all
ACCESS operations on the wire for a mount point. ACCESS operations are synchronous,
slowing applications unnecessarily if they do not use or support ACLs. Using the noacl mount
option is safe when your files are stored on N series storage systems that are accessed only
by NFS version 2 or 3.