On Thu, Sep 23, 2010 at 10:20 PM, Nicholas Tang <nicholast...@gmail.com> wrote: > A couple of quick suggestions: > > 1.) Turn on jumbo frames on the switch and the servers > 2.) Turn atime off on the receiving (writing) end - the nfs server
These were my next thoughts. I don't have an aversion to jumbo frames everywhere, other than the NFS server also runs other services (dns, a very very small LDAP) and I don't know if there will be a problem with clients expecting a smaller frame size trying to connect to a machine with a large frame size? > Also, so I understand correctly, you've got 3 machines: > > - data writer > - desktop > - nfs server > > The desktop mounts an nfs volume. The data writer sends data to the > desktop, which writes it to the nfs volume. Correct. > If that's correct, then: > > 1.) Why not write directly to the nfs server and cut out the middle > man? This could be a matter of bad drivers on the desktop or whatever > else. You could accomplish this by having the data writing box send > data straight to the nfs server, or by mounting that nfs mount on the > data writer and having it write "locally" to that mount. You could > still mount that on the desktop for reading/ access/ editing. Well, I wanted to seperate out what machines do what. What's running on this desktop now is supposed to move to a dedicated server that writes the data to NFS and also provides live streams out to any other desktops (there are four) that could ask for it. But, if the desktop can't do it, I have a problem believing the server will be any better off. Similar processing power, network ports, etc. > 2.) If you can't do that, why not write to local disk on the desktop > and then do an async move/ copy to the nfs volume? Breaks the architecture. The idea is for all this stuff to be over on the NFS server because the individual desktops dont have the storage space to make this work. > I've always found NFS performance on linux to be lackluster, although > your numbers seem unusually bad. This is what I've heard, though the "unusually bad" part seems.. bad. _______________________________________________ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
