All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wendy Cheng <s.wendy.cheng@gmail.com>
To: Brandon Simmons <brandon.m.simmons@gmail.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>, linux-nfs@vger.kernel.org
Subject: Re: Very Slow Sequential Reads over NFS from an XFS disk in Amazon EC2
Date: Fri, 12 Mar 2010 18:25:41 -0800	[thread overview]
Message-ID: <4B9AF7A5.6020100@gmail.com> (raw)
In-Reply-To: <e2c9b7261003121623n3e6697cay664ccb1c1d978d5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Brandon Simmons wrote:
> On Fri, Mar 12, 2010 at 1:33 PM, Trond Myklebust
> <trond.myklebust@fys.uio.no> wrote:
>   
>> On Fri, 2010-03-12 at 13:22 -0500, Brandon Simmons wrote:
>>     
>>> I am using tiobench to test performance of an NFS mounted volume, and
>>> notice that Sequential Reads are much slower than Random Reads. This
>>> isn't the behavior when I run the same test on the disk mounted
>>> locally.
>>>
>>> For random reads I'm getting:
>>>
>>>    50 MB/s  over NFS
>>>
>>> v.s
>>>
>>>    384 MB/s  when mounted locally
>>>
>>> This is in comparison to the benchmark for _Random Reads_, in which I get:
>>>
>>>    288 MB/s both over NFS _and_ when directly mounted
>>>
>>> The other benchmarks seem to be in line with what I would expect, but
>>> I'm fairly new to NFS. Why would sequential reads over NFS be sooo
>>> much slower than random reads over NFS?
>>>       
>> They're not usually. My guess is that this is an artifact of your test.
>> What is tiobench doing prior to the sequential read?
>>
>> Trond
>>     
>
> I'm wondering if this is caused by caching. my benchmark does
> Sequential Reads first, then it does Random Reads. Is it possible that
> the random reads could be working on cached data?
>
> That would mean my sequential reads aren't too slow, rather the random
> reads are extraordinarily fast because of caching. Looking at running
> some different benchmarks.
>
>   

I think so too - since your throughput are way too good (when compared 
with other I/O-bound numbers). Using simple benchmark(s) such as 
tiobench can generate very misleading results if you don't know how to 
steer away from cache effects. For NFS workload, SPECsfs is a much 
better benchmark but it is cumbersome to run (and you have to pay for 
it, I think).

In general, however, I find sequential read performance hard to predict 
in a virtual environment. This is because the data can be (physically) 
scattered around. It takes non-trivial efforts for system software to 
get its pre-fetch logic right.

-- Wendy


      parent reply	other threads:[~2010-03-13  2:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11 21:40 [NFS] Very Slow Sequential Reads over NFS from an XFS disk in Amazon EC2 Brandon Simmons
2010-03-12 18:22 ` Brandon Simmons
     [not found]   ` <e2c9b7261003121022p40a5c382r3b0ca65e91d02622-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-12 18:30     ` Ric Wheeler
2010-03-12 19:09       ` Brandon Simmons
     [not found]         ` <e2c9b7261003121109p62b6587eh18cabd101511763b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-12 19:19           ` Ric Wheeler
2010-03-12 18:33     ` Trond Myklebust
     [not found]       ` <1268418808.8154.7.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-13  0:23         ` Brandon Simmons
     [not found]           ` <e2c9b7261003121623n3e6697cay664ccb1c1d978d5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-13  2:25             ` Wendy Cheng [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=4B9AF7A5.6020100@gmail.com \
    --to=s.wendy.cheng@gmail.com \
    --cc=brandon.m.simmons@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /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.