Re: nfs is very slow

From: Vineet Kumar (debian-user_at_virtual.doorstop.net)
Date: 08/09/03

  • Next message: Nyc0n: "linux cluster"
    Date: Fri, 8 Aug 2003 23:49:46 -0700
    To: debian-user@lists.debian.org
    
    
    

    * Gregor Stößer (stoesser@chemie.uka.de) [030808 00:37]:
    > On Thu, Aug 07, 2003 at 05:39:55PM +0200, Nicos Gollan wrote:
    > > On Thursday 07 August 2003 14:01, Gregor Stößer wrote:
    > > > I'm having some trouble with my nfs-server. Performance is very bad, but
    > > > all ather protocols (ftp, http, scp) are quite fast.
    > >
    > > ftp, http et al. use TCP connections while NFS per default uses UDP packets.
    > > More recent kernels have experimental support for NFS over TCP. In your case
    > > (fast network where latency is a very limiting factor), there might be a
    > > problem with NFS sending small packages and needing confirmation on every
    > > one, thus adding a huge overhead, while TCP scales better. If you find a way
    > > to increase packet sizes - gigabit ethernet should support around 65kB -, you
    > > might actually see a performance increase.
    >
    > I'm using already read- and write sizes of 64kB, that's not the point.
    > But NFS over TCP might be worth trying. Nevertheless, my machine worked
    > without any problem for more than a year, so changing from UDP to TCP
    > might help, but there must be some other reason.

    It's worth a try. Using large rsize and wsize (like you're doing) can
    help, to a certain extent, but it can also hurt, if your network drops
    any packets at all. When NFS asks to send a 64kb packet, it is actually
    sent as a bunch of fragments. If but one of those fragments is lost,
    the whole thing is lost. UDP provides no reliability. When NFS reaches
    its timeout and realizes that the packet never arrived, the whole thing
    needs to be sent again. TCP improves on the situation greatly since one
    lost packet means just that one packet gets retransmitted, not the whole
    64kb again. You could also try sticking with UDP and _lowering_ rsize
    and wsize to 8k or even less, to reduce the number of failed
    reassemblies.

    good times,
    Vineet

    -- 
    http://www.doorstop.net/
    -- 
    #include<stdio.h>
    int main() {
        puts("Reader! Think not that \n"
             "technical information \n"
             "ought not be called speech;");
        return 0;
    }
    
    

    -- 
    To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    


  • Next message: Nyc0n: "linux cluster"

    Relevant Pages

    • Re: Incoherent E-mails
      ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
      (alt.computer.security)
    • SuSE 10.0 NFS vs. Firewall
      ... I am attempting to get NFS working; both client and server are running ... 3/min burst 5 LOG level warning tcp-options ip-options prefix ... 3/min burst 5 state NEW udp dpt:sunrpc LOG level warning tcp-options ... 3/min burst 5 state NEW tcp dpt:sunrpc LOG level warning tcp-options ...
      (alt.os.linux.suse)
    • Re: Firewall problems with NFS
      ... It seems to only allow use as an NFS client, since that worked fine when I tested it. ... U was surprised to see that TCP with tcp_adv_win_size=5 and rsize=8192 was as fast as UDP, ... 100005 1 udp 841 mountd ...
      (Fedora)
    • Trying to get NFS working with FreeBSD & OS X
      ... NFS client on a Mac OS X box. ... 100000 4 tcp 111 portmapper ... 100000 4 udp 111 portmapper ... 100021 0 udp 617 nlockmgr ...
      (comp.unix.bsd.freebsd.misc)
    • Trouble making NFS work with Mac OS X
      ... NFS client on a Mac OS X box. ... 100000 4 tcp 111 portmapper ... 100000 4 udp 111 portmapper ... 100021 0 udp 617 nlockmgr ...
      (freebsd-net)