Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

How can I achieve low latency for NFS exports in order to e.g. have developers work nicely in Eclipse/Visual Studio with their workspaces mounted over NFS?

share|improve this question

5 Answers 5

up vote 6 down vote accepted

This sounds like you're still in the design stage. If that's true, a few things to look at are:

  • NFSv3/4 over NFSv2, to allow for larger packets, and features like "safe asynchronous write"
  • Check your NFS client for read-ahead and delayed write, both of those features will help
  • Obviously keep network latency low - GBit connections over a fast switch
  • Make sure your NFS server is tuned for speed. That's both the NFS implementation, and how it is configured.

There's a good NFS FAQ, including some tuning tips, over yonder: http://nfs.sourceforge.net/

share|improve this answer
2  
It's worth pointing out that on modern linux, it's probably better to not specify any options as it'll do a better job at using the best values than you will. –  David Pashley Jun 5 '09 at 8:18

It's interesting that most NFS information I see is about configuring NFS itself whereas beyond the basics, most performance is going to come from the network infrastructure and influenced by traffic load.

The NFS response stack on Open Solaris is about 10-50us where as typical latency via ping on systems I see with a single switch between is around 500us +/- 300us. Assuming the NFS client side is around the same order of magnitude as the server 10-50us then imagine we completely remove the NFS overhead at both ends completely then we save at most 100us out of 500us. Yes a 20% improvement on a 500us journey but I want more. How can I get it? Where is the other 400us coming from? Is it from the ping stack on the client and server or is it the switch? It's certainly not wire speed which is about 5ns/meter. I doubt the ping O/S stack is much influence if 32K NFS response can be treated in 10us. Seems that the candidates are the NIC, Network stack and switch and of the three where is it coming from. A typical switch introduces about 100us from what I can find in research and upto 300us for 32K transfers.

Now is the solution to use cut through switches. From literature from for example Force10, a cut through switch can take the times down to sub-us into the ns range.

How about NICs? how much variation is there in NIC performance?

I'm suprised at the lack of quantitative measures and information on network latency and how much guesswork such as "oh the amount of traffic influences it"

My plan is to do some direct connect tests without switches and put in one switch, then two and look a the latency impact.

I want to do NIC testing but it's not so simple and I don't have much gear. I will be able to test Broadcom verses Intel.

share|improve this answer
    
This needs to be its own question, not an answer to another question. –  sysadmin1138 Mar 13 '11 at 6:37
    
Yes, I agree, it should be it's own question. The question will be asked when I get more data, but for now, what I wrote, I would be interested in if I had asked the question, so I thought the asker might be interest as well, plus I want my comments to spark some other more informed responses. –  Kyle Hailey Mar 14 '11 at 5:48

Put the files on a very fast disk or a built-for-speed RAID array since disk IO will determine the lower bound on your latency whether the client is local or remote. The other answers are also OK.

A nice solution is to make the file server be a build server also.

share|improve this answer

Don't compile over NFS. NFS performance is usually a factor of the disk I/O performance and compiling is what's going to drive your number of file I/O ops.

If you can't avoid that, caching is what will save the day. Cram that NFS server as full of RAM as you can, use asynchronous writes and enable all caching you can client-side. The fact is that a RAID is no better at handling (non-cached) disk operations then a single hard disk. And with the small file sizes of a compilation workload, combined throughput won't change a thing.

share|improve this answer

Wait for filesystem caching, or don't do compiles over NFS. Hard disks are always going to be quicker than network filesystems.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.