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
prev 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.