From: Benny Halevy <bhalevy@panasas.com>
To: Krishna Kumar2 <krkumar2@in.ibm.com>
Cc: linux-nfs@vger.kernel.org, Peter Staubach <staubach@redhat.com>
Subject: Re: NFS performance degradation of local loopback FS.
Date: Mon, 23 Jun 2008 15:40:40 +0300 [thread overview]
Message-ID: <485F99C8.2000800@panasas.com> (raw)
In-Reply-To: <OF5D1728DA.B4C6E2E0-ON65257471.0027ACA3-65257471.002CF647@in.ibm.com>
On Jun. 23, 2008, 11:11 +0300, Krishna Kumar2 <krkumar2@in.ibm.com> wrote:
> Hi Benny,
>
>> According to dd's man page, the f{,date}sync options tell it to
>> "physically write output file data before finishing"
>> If you kill it before that you end up with dirty data in the cache.
>> What exactly are you trying to measure, what is the expected application
>> workload?
>
> I changed my test to do what you were doing instead of killing
> dd's, etc. The end application is DB2 and it is using multiple
> processes and I wanted to simulate that with micro-benchmarks.
> The only reliable way to benchmark bandwidth for multiple
> processes is to kill the tests after running them for some time
> instead of letting them run till conclusion.
BTW, iozone (http://www.iozone.org/) might be your friend if you're
looking for a reliable I/O benchmark (w/ -e and -c options to include
fsync and close).
>
>> ext3 mount options: noatime
>> nfs mount options: rsize=65536,wsize=65536
>> dd options: bs=64k count=10k conv=fsync
>>
>> (write results average of 3 runs)
>> write local disk: 47.6 MB/s
>> write loopback nfsv3: 30.2 MB/s
>> write remote nfsv3: 29.0 MB/s
>> write loopback nfsv4: 37.5 MB/s
>> write remote nfsv4: 29.1 MB/s
>>
>> read local disk: 50.8 MB/s
>> read loopback nfsv3: 27.2 MB/s
>> read remote nfsv3: 21.8 MB/s
>> read loopback nfsv4: 25.4 MB/s
>> read remote nfsv4: 21.4 MB/s
>
> I used the exact same options you are using, and here is the results
> averaged across 3 runs:
>
> Write local disk 58.5 MB/s
> Write loopback nfsv3: 29.42 MB/s (50% drop)
>
> Reading (file created from /dev/urandom, somehow I am getting in GB/sec
> while your results were comparable to write's):
Apparently the file is cached. You needed to restart nfs
and remount the file system to make sure it isn't before reading it.
Or, you can create a file larger than your host's cache size so
when you write (or read) it sequentially, its tail evicts its head
out of the cache. This is a less reliable method, yet creating a
file about 25% larger than the host's memory size should work for you.
Benny
> Read local disk: 2.77 GB/s
> Read loopback nfsv3: 2.86 GB/s (higher for some reason)
>
> Thanks,
>
> - KK
>
next prev parent reply other threads:[~2008-06-23 12:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 6:46 NFS performance degradation of local loopback FS Krishna Kumar2
2008-06-19 9:58 ` Krishna Kumar2
2008-06-19 12:04 ` Peter Staubach
2008-06-19 12:52 ` Benny Halevy
2008-06-20 6:39 ` Krishna Kumar2
2008-06-20 9:21 ` Krishna Kumar2
2008-06-22 8:35 ` Benny Halevy
2008-06-23 8:11 ` Krishna Kumar2
2008-06-23 12:40 ` Benny Halevy [this message]
2008-06-26 7:19 ` Krishna Kumar2
2008-06-26 17:42 ` Chuck Lever
2008-06-26 17:55 ` J. Bruce Fields
2008-06-26 21:05 ` Chuck Lever
[not found] ` <76bd70e30806261405g9357c6fg51b973ff076ee78b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-06-26 21:22 ` kernel hacker's pub night J. Bruce Fields
2008-06-26 21:24 ` J. Bruce Fields
2008-06-27 7:14 ` Benny Halevy
2008-06-27 9:04 ` NFS performance degradation of local loopback FS Krishna Kumar2
2008-06-27 14:06 ` Chuck Lever
[not found] ` <76bd70e30806270706x7cbfd291l6cb6d0cc5e81771-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-06-30 9:57 ` Krishna Kumar2
2008-06-30 15:25 ` Chuck Lever
[not found] ` <76bd70e30806300825t6490477dpb8ce3ee48a0a6777-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-01 3:43 ` Krishna Kumar2
2008-06-27 17:44 ` J. Bruce Fields
2008-06-27 18:06 ` Dean Hildebrand
2008-06-30 10:10 ` Krishna Kumar2
2008-06-30 15:26 ` Jeff Layton
[not found] ` <20080630112654.012ce3e4-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2008-06-30 15:35 ` J. Bruce Fields
2008-06-30 16:00 ` Chuck Lever
2008-07-01 10:19 ` Krishna Kumar2
2008-07-01 12:47 ` Jeff Layton
2008-06-30 15:35 ` Chuck Lever
2008-07-01 5:07 ` Krishna Kumar2
2008-06-30 15:30 ` Chuck Lever
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=485F99C8.2000800@panasas.com \
--to=bhalevy@panasas.com \
--cc=krkumar2@in.ibm.com \
--cc=linux-nfs@vger.kernel.org \
--cc=staubach@redhat.com \
/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