Linux NFS development
 help / color / mirror / Atom feed
From: Ian Thurlbeck <ian@stams.strath.ac.uk>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: nfs@lists.sourceforge.net
Subject: Re: Strange delays on NFS server (with piccies)
Date: Thu, 26 Aug 2004 12:01:42 +0100	[thread overview]
Message-ID: <412DC316.6080709@stams.strath.ac.uk> (raw)
In-Reply-To: <16683.8588.18082.190876@cse.unsw.edu.au>

Neil Brown wrote:
> On Monday August 16, ian@stams.strath.ac.uk wrote:
> 
>>I bumped the nfsd's up to 64 (from 32) and subjectively the problem gets 
>>worse.  I then reduced them to 16 and things are a bit better...
> 
> 
> Odd.
> 
> 
>>Would changing some of the bdflush settings help at all?
> 
> 
> Maybe.  I would start with
>   echo 200 > /proc/sys/vm/dirty_expire_centisecs
> 
> You said you are using ext3.  Are you using journal=data or the
> default journal=ordered ??
> 
> Also, it would be interesting to compare nfs ops per second against
> disk i/os per second over time.
> Something like..
> 
>   while :
>   do
>     perl -ne 'if (/^proc3/)  { @a=split ; shift @a; shift @a; print eval(join("+", @a))."  ";}' /proc/net/rpc/nfsd
>     perl -ne 'if (/hda /) { @a=split; print $a[9]."\n";}' /proc/diskstats  
>     sleep 1
>   done | perl -ne '@_=split; print( ($_[0]-$a[0])." ".($_[1]-$a[1])."\n"); @a=@_;'
> 
> If the pauses correspond to periods with very low nfs ops/sec and very
> high writes per second, then it confirms that it is a disk flushing
> problem.
> 
> It would also be interesting to see if there was a pattern in the
> timing, particular how long the interval was between one pause and the
> next.  
> Also getting these sets of number for different numbers of nfsd
> threads could turn your subjective impression into objective data.
> 
> NeilBrown

Neil, and others

I've gathered some useful data (I hope) on the problem. I ran a variant 
of Neil's script for 2.4 kernel for most of a day (9.30-15.00).

It's all here:

http://www.stams.strath.ac.uk/~ian/nfs/

Files:
data.all.raw	raw data, 3 columns: HH:MM:SS nfsops diskwrites
data.all.plot	massaged data, 3 columns: SECONDS nfsops diskwrites
data.all.eps	postscript plot of massaged data
data.all.gif	gif plot of massaged data

(The massaged data has had missing data filled in. Sometimes the
seconds field jumps 2 seconds. HH:MM:SS changed to seconds from start)

I think this shows no correlation between NFS ops and disk writes
with respect to these big slowdowns (the big peaks in lower graph, there
are 5). Something with a periodicity of 600 seconds is also writing to
the disk. (This was done with 32 nfsd threads, BTW)

There is another similar set of files zooming in on the first 2
events (data.zoom.*). You can see from this graph that in the disk 
writing event lasts about 50 seconds, and the client machines hang on 
NFS ops for this period (pretty annoying, I can tell you!).

Also in the directory is the output of "vmstat 1" showing one of these
events (vmstat.log).

Can anyone deduce anything from this?

Many thanks

Ian

PS: How big are these "wsect" counts in /proc/partitions in terms of bytes ?

-- 
Ian Thurlbeck                http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK,  G1 1XH
Tel: +44 (0)141 548 3667           Fax: +44 (0)141 552 2079



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  parent reply	other threads:[~2004-08-26 11:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-11 10:55 Strange delays on NFS server Ian Thurlbeck
2004-08-11 11:58 ` Olaf Kirch
2004-08-11 12:58 ` Steve Dickson
2004-08-11 16:08   ` Ian Thurlbeck
2004-08-11 16:41     ` Olaf Kirch
2004-08-11 16:53       ` Phy Prabab
2004-08-11 16:57       ` Christoph Hellwig
2004-08-11 19:42       ` Norman Weathers
2004-08-12  8:04       ` Ian Thurlbeck
2004-08-12 15:15       ` Ian Thurlbeck
2004-08-13 14:53         ` Steve Dickson
2004-08-16 12:40           ` Ian Thurlbeck
     [not found]             ` <20040816131434.GL3510@suse.de>
     [not found]               ` <4120C8D5.3040606@stams.strath.ac.uk>
     [not found]                 ` <20040816145435.GQ3510@suse.de>
     [not found]                   ` <4124CD95.7020007@stams.strath.ac.uk>
     [not found]                     ` <20040820095854.GC23176@suse.de>
2004-08-24  9:48                       ` Ian Thurlbeck
2004-08-24 10:27                         ` Jan Bruvoll
2004-08-25  2:02                         ` Greg Banks
2004-08-25  8:40                           ` Ian Thurlbeck
2004-08-25 10:02                             ` Greg Banks
2004-08-25 10:36                               ` Ian Thurlbeck
2004-08-24 11:07             ` Neil Brown
2004-08-24 14:22               ` Ian Thurlbeck
2004-08-24 23:54                 ` Neil Brown
2004-08-26 11:01               ` Ian Thurlbeck [this message]
2004-08-27  1:22                 ` Strange delays on NFS server (with piccies) Neil Brown
2004-08-27  4:10                   ` Greg Banks
2004-08-11 19:07     ` Strange delays on NFS server Steve Dickson

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=412DC316.6080709@stams.strath.ac.uk \
    --to=ian@stams.strath.ac.uk \
    --cc=neilb@cse.unsw.edu.au \
    --cc=nfs@lists.sourceforge.net \
    /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