linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Wright <jeff.wright@oracle.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org,
	Craig Flaskerud <Craig.flaskerud@oracle.com>,
	Andy Adamson <androsadamson@gmail.com>
Subject: Re: Diagnosing and resolving bottleneck with NFS I/O
Date: Fri, 22 Jun 2012 08:42:44 -0600	[thread overview]
Message-ID: <4FE48464.5020706@oracle.com> (raw)
In-Reply-To: <AF35F0DD-427A-4CC5-8E96-DEE760757762@oracle.com>

On 06/21/12 15:17, Chuck Lever wrote:
> Hi-
>
> On Jun 21, 2012, at 3:40 PM, Jeff Wright wrote:
>
>> To simplify analysis we ran an application that would time the execution of stable pwrite64() (O_DIRECT) for a single I/O.  We observed a large increase in response time at the application (time to run pwrite64()) compared to the reported response time from nfsiostat.  We also measured that the response time measured by nfsiostat on the client closely matched the back-end media response time in the server, and that the RPC backlog was 0.  netstat showed that we had some data in the TCP send queue on the client, but not overloaded, and that we had very little data in the TCP receive queue on the server.  The values of the I/O rate and response time in this test were as follows:
>> * Application I/O rate: 102 IOPS
>> * Application I/O response time: 9.9 ms
>> * nfsstat I/O rate: 102 IOPS
>> * nfsstat I/O response time (RTT): 3.8 ms
>> * NFS server I/O rate: 104
>> * NFS server I/O response time: 1.5 ms
>> * Media I/O rate: 105 IOPS
>> * Media I/O response  time: 3.2 ms
>>
>> In this use case I think we have unstable writes from the NFS client followed by commits, and this would lead to the short NFS server write response time because the commit is not included.  The nfsstat response time matching the media response time would be correct if the nfsstat response time included the commit time for the I/O.  Could anyone verify if the RTT reported includes the the total time to commit the writes, or if it only includes the write and not the subsequent commit?
> It depends on whether the server performs a FILE_SYNC or UNSTABLE write.  nfsiostat doesn't distinguish between them, and the server is free to promote an UNSTABLE write request to a FILE_SYNC write.
>
> If a write is UNSTABLE, then no, the "commit" time is not included in the WRITE RTT statistic.  If a write is FILE_SYNC, then the "commit" time is built into the WRITE request, and the WRITE RTT statistic includes it.
>
> Servers generally don't promote UNSTABLE writes, but NetApp always does.  Clients seldom request FILE_SYNC writes, though they will in some circumstances.
We will check what the S11 nfsd implementation is doing - thanks for the 
clarification.
>


      reply	other threads:[~2012-06-22 14:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-21 19:40 Diagnosing and resolving bottleneck with NFS I/O Jeff Wright
2012-06-21 21:17 ` Chuck Lever
2012-06-22 14:42   ` Jeff Wright [this message]

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=4FE48464.5020706@oracle.com \
    --to=jeff.wright@oracle.com \
    --cc=Craig.flaskerud@oracle.com \
    --cc=androsadamson@gmail.com \
    --cc=chuck.lever@oracle.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).