Poor write performance on Debian server running NFS with 22TB exported JFS filesystem

I am currently running a debian server that is exporting a large JFS filesystem (22TB) over NFS (nfs-kernel-server.) When attempting to write to the NFS share, the performance is very poor. The 22TB disk is sitting on a NAS mounted using iSCSI.

• It will bust for a moment near expected line speed, and then sit idle for several seconds. Very little traffic measured in the low kb/sec.
• The wait peeks on write.
• When reading from the NFS mount, the system operates at expected speeds (11MB/sec).
• The issue does not occur when using SFTP, rsync, or local coping (non-nfs).
• The issue persists between stable and testing releases.
• On the same machine I have a 14TB ext4 filesystem using the exact same export configuration that does not share the issue. This share is not in regular use and thus not consuming resources.

NFS Server:

cat /etc/exports
/data2      10.1.20.86(rw,no_subtree_check,async,all_squash)

cat /sys/block/sdb/queue/scheduler
noop [deadline] cfq

cat /etc/default/nfs-kernel-server 
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=--manage-gids
NEED_SVCGSSD=
RPCSVCGSSDOPTS=

NFS Client:

cat /etc/fstab
10.1.20.100:/data2  /root/incoming  nfs     rw,noatime,soft,intr,noacl 0 2

cat /sys/block/sdb/queue/scheduler
noop [deadline] cfq

cat /proc/mounts
10.1.20.100:/data2/ /root/incoming nfs4 rw,noatime,vers=4,rsize=262144,wsize=262144,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.1.20.86,minorversion=0,addr=10.1.20.100 0 0

This problem has me pretty stumped. Any help would be greatly welcomed. Thanks.

My guess is that the number of NFS server threads is too low. Instead of 8, the number should be much higher.

8 threads would probably be enough for shares that contain only small files and are accessed by a very small number of clients (e.g. in a home network) or on slow networks (10 Mbit).

Try to determine the retrans value on your NFS server during writing:

nfsstat -r

If you get transmission retries, increase the number of server threads.

And I think it would be save to remove the rsize / wsize / tcp settings from your mount options. TCP is the default protocol anyway and with TCP it is not necessary to limit the transfer size.