From: Daniel Pocock <daniel@pocock.com.au>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: extremely slow nfs when sync enabled
Date: Tue, 08 May 2012 13:43:53 +0000 [thread overview]
Message-ID: <4FA92319.6000007@pocock.com.au> (raw)
In-Reply-To: <20120508124559.GA15448@fieldses.org>
On 08/05/12 12:45, J. Bruce Fields wrote:
> On Tue, May 08, 2012 at 12:06:59PM +0000, Daniel Pocock wrote:
>>
>>
>> On 07/05/12 17:18, J. Bruce Fields wrote:
>>> How many file creates per second?
>>>
>>
>> I ran:
>> nfsstat -s -o all -l -Z5
>> and during the test (unpacking the tarball), I see numbers like these
>> every 5 seconds for about 2 minutes:
>>
>> nfs v3 server total: 319
>> ------------- ------------- --------
>> nfs v3 server getattr: 1
>> nfs v3 server setattr: 126
>> nfs v3 server access: 6
>> nfs v3 server write: 61
>> nfs v3 server create: 61
>> nfs v3 server mkdir: 3
>> nfs v3 server commit: 61
>
> OK, so it's probably creating about 60 new files, each requiring a
> create, write, commit, and two setattrs?
>
> Each of those operations is synchronous, so probably has to wait for at
> least one disk seek. About 300 such operations every 5 seconds is about
> 60 per second, or about 16ms each. That doesn't sound so far off.
>
> (I wonder why it needs two setattrs?)
I checked that with wireshark:
- first SETATTR sets mode=0644 and atime=mtime=`set to server time'
- second SETATTR sets atime and mtime using client values (atime=now,
mtime= some time in the past)
Is this likely to be an application issue (e.g. in tar), or should the
NFS client be able to merge those two requests somehow?
If I add `m' to my tar command (tar xzmf) the nfsstat results change:
nfs v3 server total: 300
------------- ------------- --------
nfs v3 server setattr: 82
nfs v3 server lookup: 17
nfs v3 server access: 5
nfs v3 server write: 90
nfs v3 server create: 83
nfs v3 server mkdir: 3
nfs v3 server remove: 15
nfs v3 server commit: 5
and iostat reports that w/s is about the same (290/sec) but throughput
is now in the region 1.1 - 1.5MBytes/sec
Without using `m', here are the full stats from the Z800 acting as NFSv3
server:
nfs v3 server total: 299
------------- ------------- --------
nfs v3 server setattr: 132
nfs v3 server access: 6
nfs v3 server write: 88
nfs v3 server create: 62
nfs v3 server mkdir: 6
nfs v3 server commit: 5
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s
avgrq-sz avgqu-sz await svctm %util
dm-10 0.00 0.00 0.00 294.00 0.00 1.15
8.00 1.04 3.55 3.26 95.92
The other thing that stands out is this:
avgrq-sz = 8 (units = 512 byte sectors)
If the server filesystem is btrfs, the wMB/s figure is the same, but I
notice avgrq-sz = 16, so it seems to be combining more requests into
bigger writes
Here is the entry from /proc/mounts:
/dev/mapper/vg01-test1 /mnt/test1 ext4
rw,relatime,barrier=1,data=ordered 0 0
next prev parent reply other threads:[~2012-05-08 13:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-06 3:00 extremely slow nfs when sync enabled Daniel Pocock
2012-05-06 18:23 ` Myklebust, Trond
2012-05-06 21:23 ` Daniel Pocock
2012-05-06 21:49 ` Myklebust, Trond
2012-05-06 22:12 ` Daniel Pocock
2012-05-06 22:12 ` Daniel Pocock
2012-05-06 22:42 ` Myklebust, Trond
2012-05-07 9:19 ` Daniel Pocock
2012-05-07 13:59 ` Daniel Pocock
2012-05-07 17:18 ` J. Bruce Fields
2012-05-08 12:06 ` Daniel Pocock
2012-05-08 12:45 ` J. Bruce Fields
2012-05-08 13:29 ` Myklebust, Trond
2012-05-08 13:43 ` Daniel Pocock [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-05-06 9:26 Daniel Pocock
2012-05-06 11:03 ` Daniel Pocock
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=4FA92319.6000007@pocock.com.au \
--to=daniel@pocock.com.au \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.