Re: nfs is very slow
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 8 Aug 2003, Vineet Kumar wrote:
> * 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
That's not quite true, tcp helps by doing the work for you, but it always
has to send data sequencially, if a packet in the middle is lost, it
has no way of acknoledging that it has received any further data and may
cause the server to retransmit the newer data even though it is only
missing data from an earlier message.
> and wsize to 8k or even less, to reduce the number of failed
> reassemblies.
>
> good times,
> Vineet
>
- --
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/Nuww+vN6RuSjKAwRAv/6AKC6DExF7OmqqCbtavmk/eWNFw39lwCguEU4
OOfwK81RVZBuT24sEp6/0e8=
=+job
-----END PGP SIGNATURE-----
Reply to: