Linux NFS development
 help / color / mirror / Atom feed
From: Jean-Noel Bouvier <jean-noel.bouvier@imag.fr>
To: Neil Brown <neilb@suse.de>
Cc: rich@hq.vsaa.lv, nfs@lists.sourceforge.net
Subject: Re: poor nfs performance & hangs with latest kernels
Date: Wed, 21 Feb 2007 14:40:03 +0100	[thread overview]
Message-ID: <45DC4BB3.7090706@imag.fr> (raw)
In-Reply-To: <17882.49990.799201.335846@notabene.brown>

Hello,

I encounter the same NFS bad performance for kernels newer than 2.6.16.31

Tests : tar -xvf linux-2.4.32.tar

Environment :
- client 2.6.16.31
- client mounts a XFS file system through NFS on a remote machine with
options = rw,tcp,intr
- server : exporting file system with options = rw,sync,insecure

Results : (according to server kernel version)
2.6.15.7 => 1 minute 10 sec
2.6.16.31 => 1 minute 02 sec
2.6.17.14 => 15 minutes
2.6.18.3 => 15 minutes

Neil Brown wrote:
> On Monday February 19, rich@hq.vsaa.lv wrote:
> 
>>hi. i am having a pretty weird nfs performance problems.
>>(please, cc me, as i am not on the list).
>>
>>when there is some intensive nfs activity (write), all other nfs 
>>operations slow down to crawl or even stop at all during that time.
>>
>>i have been able to reproduce the problem with kernel versions 
>>2.6.16.40, 2.6.19.2 and 2.6.20 (on  slackware-11.0).
>>another person reproduced the hang with 2.6.19-1.2911.fc6 (fedora core 6).
> 
> 
> Are there any kernels where you cannot reproduce the problem?

2.6.16.31 and 2.6.15.7 are OK.

>>when the problem appears, access to the same data both locally and even 
>>over ssh is happening  without any slowdown, but nfs access is sometimes 
>>slowed down significantly, in some cases  even being unable to list a 
>>directory for 30 minutes.
>>in some cases, not only nfs slowdown happens, but whole system hangs.
> 
> 
> So we need to find out exactly what is happening when things slow
> down.
> Some things that might be useful:
>   a tcpdump trace (use -s 0) of traffic which things are going slowly.
>   "cat /proc/meminfo /proc/slabinfo".  Get a copy when everything is
>      fine, then another few then things are going slowly.
>   Maybe "echo t > /proc/sysrq-trigger" and collect the kernel logs.
>     If some processes are in 'D' status, this could give useful
>     information.

Results :

- 2.6.16.31 : load average 1; 5 threads and nfsd process are never with
'D' status.
- 2.6.18.3 : load average 5; 2 threads and nfsd process are often with
'D' status.

> Get the various information on both the server and client if
> possible.  Hopefully somewhere in all of that will be a clue.
> 
> 
>>there is one scenario where it is very easy to reproduce the problem 
>>(note : don't try this on a  remote system or one you can not afford to 
>>hard reboot) :
>>
>>export a local directory. i'm using 
>>localhost(rw,no_root_squash,sync,no_subtree_check).
>>mount it locally and try to perform a write operation :
>>dd if=/dev/zero of=/mounted_nfs/testfile bs=512k count=2048
> 
> 
> This scenario is known to cause problems, is very hard to fix, and is
> a case of "well don't do that then".  The problems here are probably
> unrelated to the problems you are having between separate machines.
> 
> 
>>using 2.6.16.21, i was unable to hang my workstation, but server, even 
>>though it survived the test, is still having excessive load (~ 4). top 
>>lists as most resource hungry processes nfsd, kjournald and
>>kblockd.
> 
> 
> So 2.6.16.21 survives but 2.6.16.40 doesn't?  Is that a reliable
> result?  Is that with separate server and client, or server and client
> on the same machine?
> 
> NeilBrown
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs






-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  parent reply	other threads:[~2007-02-21 13:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-19 14:49 poor nfs performance & hangs with latest kernels Rich
2007-02-20  9:45 ` Neil Brown
2007-02-20 12:45   ` Rich
2007-02-21 13:40   ` Jean-Noel Bouvier [this message]
2007-02-22  2:28     ` Neil Brown
2007-02-22 19:42       ` Norman Weathers
2007-02-22 20:34         ` Trond Myklebust
2007-03-05 13:30       ` Jean-Noel BOUVIER

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DC4BB3.7090706@imag.fr \
    --to=jean-noel.bouvier@imag.fr \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    --cc=rich@hq.vsaa.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox