NFS Transfers Dramatically Slow Down PC

rocktorrentz · 2007-09-22 14:06:35

I have a Debian Etch Box acting as a file server with the following exports file:

/home/sam 192.168.1.67(rw,no_subtree_check)
/home/shared 192.168.1.67(rw,no_subtree_check)

I mount them on my Arch Desktop with the following fstab lines:

192.168.1.100:/home/sam    /media/server/sam    nfs    rsize=8192,wsize=8192    0    1
192.168.1.100:/home/shared    /media/server/shared    nfs    rsize=8192,wsize=8192    0    1

My problem is that every time I transfer large files to the server (from it is fine), I can't do much on my PC because it will cause the transfer to stall and because everything becomes very slow. The transfer rates are an average of about 8MB/s from the box and about 5MB/s to it (when not doing anything) which I find acceptable for my 100mbit network. The odd thing is that my CPU usage is barely affected by the transfer and my memory usage is also not abnormally high (I have a Core 2 Duo system with 1GB Ram). Does anyone know how to fix this problem?

rocktorrentz

Urkburk · 2008-01-09 21:47:53

I have the exact same problem (And same system setup... Even the same CPU xD)

Ideas anyone?

Alethos · 2008-01-09 23:56:00

Those r&wsize values look pretty small...they are the default (as you see) values for v2. You should try a minumum of 32768 then de/increase in increments of 1024 until you get a comfortable speed.

The info below is from http://publib.boulder.ibm.com/infocente … s_perf.htm

The following reasons outline why you might want to change the read and write size values:

* The server might not be capable of handling the data volume and speeds inherent in transferring the read/write packets, which are 8 KB for NFS Version 2 and 32 KB for NFS Version 3 and NFS Version 4. This might be the case if a NFS client is using a PC as an NFS server. The PC may have limited memory available for buffering large packets.
* If a read/write size value is decreased, there may be a subsequent reduction in the number of IP fragments generated by the call. If you are dealing with a faulty network, the chances of a call and reply pair completing with a two-packet exchange are greater than if there must be seven packets successfully exchanged. Likewise, if you are sending NFS packets across multiple networks with different performance characteristics, the packet fragments may not all arrive before the timeout value for IP fragments.

Reducing the rsize and wsize values might improve the NFS performance in a congested network by sending shorter packets for each NFS-read reply and write request. But, a side effect of this is that more packets are needed to send data across the network, increasing total network traffic, as well as CPU utilization on both the server and client.

If your NFS file system is mounted across a high-speed network, such as Gigabit Ethernet, larger read and write packet sizes might enhance NFS file system performance. With NFS Version 3 and NFS Version 4, you can set the rsize and wsize values as high as 65536 when the network transport is TCP. The default value is 32768. With NFS Version 2, the maximum values for the rsize and wsize options is 8192, which is also the default.

Urkburk · 2008-01-10 00:26:30

Alethos wrote:

Those r&wsize values look pretty small...they are the default (as you see) values for v2. You should try a minumum of 32768 then de/increase in increments of 1024 until you get a comfortable speed.
The info below is from http://publib.boulder.ibm.com/infocente … s_perf.htm
The following reasons outline why you might want to change the read and write size values:
* The server might not be capable of handling the data volume and speeds inherent in transferring the read/write packets, which are 8 KB for NFS Version 2 and 32 KB for NFS Version 3 and NFS Version 4. This might be the case if a NFS client is using a PC as an NFS server. The PC may have limited memory available for buffering large packets.
* If a read/write size value is decreased, there may be a subsequent reduction in the number of IP fragments generated by the call. If you are dealing with a faulty network, the chances of a call and reply pair completing with a two-packet exchange are greater than if there must be seven packets successfully exchanged. Likewise, if you are sending NFS packets across multiple networks with different performance characteristics, the packet fragments may not all arrive before the timeout value for IP fragments.
Reducing the rsize and wsize values might improve the NFS performance in a congested network by sending shorter packets for each NFS-read reply and write request. But, a side effect of this is that more packets are needed to send data across the network, increasing total network traffic, as well as CPU utilization on both the server and client.
If your NFS file system is mounted across a high-speed network, such as Gigabit Ethernet, larger read and write packet sizes might enhance NFS file system performance. With NFS Version 3 and NFS Version 4, you can set the rsize and wsize values as high as 65536 when the network transport is TCP. The default value is 32768. With NFS Version 2, the maximum values for the rsize and wsize options is 8192, which is also the default.

Oh thank you, I'm forever grateful

Changing it to 32768 solved the problem. I was mislead by the wiki page, it's probably out of date here and there (http://wiki.archlinux.org/index.php/Nfs … nt_on_boot).

Now I get 8-9 MB/s transfer rate while transfering files with rsync over my 100 mbit home network - without any system slowdowns!

rocktorrentz · 2008-01-10 11:30:37

Exact same result, I'd given up on fixing this. Thanks so much I need to get a gigabit switch between my workstation and my file server though.

Alethos · 2008-01-14 20:19:40

Cool, glad it worked. Maybe someone should update the wiki? I'd feel kind of funny removing someone else's entry (or part thereof).

Urkburk · 2008-01-14 20:36:51

Alethos wrote:

Cool, glad it worked. Maybe someone should update the wiki? I'd feel kind of funny removing someone else's entry (or part thereof).

I agree, someone should... But who is that someone? xD

Maybe there's a way to mark the wiki page, so people can see it's in need of attention?

tomk · 2008-01-14 21:48:07

Wiki updated.

FYI - anyone can update the wiki, and contributors do not retain exclusive ownership of their wiki pages, so there's no reason to feel kind of funny.

Alethos · 2008-01-15 04:01:52

tomk wrote:

Wiki updated.
FYI - anyone can update the wiki, and contributors do not retain exclusive ownership of their wiki pages, so there's no reason to feel kind of funny.

Noted. However, I'm such a noob (perhaps not in years, but definitely in knowledge concerning linux) I'd hate to "fix" someone else's erroneous post with my own dubious info.

Arch Linux

#1 2007-09-22 14:06:35

NFS Transfers Dramatically Slow Down PC

#2 2008-01-09 21:47:53

Re: NFS Transfers Dramatically Slow Down PC

#3 2008-01-09 23:56:00

Re: NFS Transfers Dramatically Slow Down PC

#4 2008-01-10 00:26:30

Re: NFS Transfers Dramatically Slow Down PC

#5 2008-01-10 11:30:37

Re: NFS Transfers Dramatically Slow Down PC

#6 2008-01-14 20:19:40

Re: NFS Transfers Dramatically Slow Down PC

#7 2008-01-14 20:36:51

Re: NFS Transfers Dramatically Slow Down PC

#8 2008-01-14 21:48:07

Re: NFS Transfers Dramatically Slow Down PC

#9 2008-01-15 04:01:52

Re: NFS Transfers Dramatically Slow Down PC

Board footer