Linux NFS development
 help / color / mirror / Atom feed
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
> 


  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