• Choose a category
• All
• Classic-Fiction

By Root 463 0

In this case, packets are never making it to the server, and the network interfaces of client and server, as well as the network itself, should be examined. NFS does not query the lower protocol layers to determine where packets are being consumed; to NFS the entire RPC and transport mechanisms are a black box. Note that NFS is like spray in this regard — it doesn't matter whether it's the local host's interface, network congestion, or the remote host's interface that dropped the packet — the packets are simply lost. To eliminate all network-related effects, you must examine each of these areas.

* * *

[3] The effect of NVRAM is discussed in Section 16.5.4.2 later in this chapter.

Server tuning

If the server is not able to field new requests or efficiently schedule and handle those that it does receive, then overall performance suffers. In some cases, the only way to rectify the problem is to add a new server or upgrade existing hardware. However, identification of the problem areas should be a prerequisite for any hardware changes, and some analyses may point to software configuration changes that provide sufficient relief. The first area to examine is the server's CPU utilization.

CPU loading

The CPU speed of a pure NFS server is rarely a constraining factor. Once the nfsd thread gets scheduled, and has read and decoded an RPC request, it doesn't do much more within the NFS protocol that requires CPU cycles. Other parts of the system, such as the Unix filesystem and cache management code, may use CPU cycles to perform work given to them by NFS requests. NFS usually poses a light load on a server that is providing pure NFS service. However, very few servers are used solely for NFS service. More common is a central server that performs mail spool and delivery functions, serves telnet, and provides NFS file service.

There are two aspects to CPU loading: increased nfsd thread scheduling latency, and decreased performance of server-resident, CPU-bound processes. Normally, the nfsd threads will run as soon as a request arrives, because they are running with a kernel process priority that is higher than that of all user processes. However, if there are other processes doing I/O, or running in the kernel (doing system calls) the latency to schedule the nfsd threads is increased. Instead of getting the CPU as soon as a request arrives, the nfsd thread must wait until the next context switch, when the process with the CPU uses up its time slice or goes to sleep. Running an excessive number of interactive processes on an NFS server will generate enough I/O activity to impact NFS performance. These loads affect a server's ability to schedule its nfsd threads; latency in scheduling the threads translates into decreased NFS request handling capacity since the nfsd threads cannot accept incoming requests as quickly. Systems with more than one CPU have additional horse-power to schedule and run its applications and nfsd threads. Many SMP NFS servers scale very well as CPUs are added to the configuration. In many cases doubling the number of CPUs nearly doubles the maximum throughput provided by the NFS server.

The other aspect of CPU loading is the effect of nfsd threads on other user-level processes. The nfsd threads run entirely in the kernel, and therefore they run at a higher priority than other user-level processes. nfsd threads take priority over other user-level processes, so CPU cycles spent on NFS activity are taken away from user processes. If you are running CPU-bound (computational) processes on your NFS servers, they will not impact NFS performance. Instead, handling NFS requests cripples the performance of the CPU-bound processes, since the nfsd threads always get the CPU before they do.

CPU loading is easy to gauge using any number of utilities that read the CPU utilization figures from the kernel. vmstat is one of the simplest tools that breaks CPU usage into user, system, and idle time components:

% vmstat 10

procs memory page disk faults cpu

r b w swap free re mf pi po fr de sr dd f0 s0 -- in