All of lore.kernel.org
 help / color / mirror / Atom feed
From: "jehan.procaccia" <jehan.procaccia@int-evry.fr>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Jeff Blaine <jblaine@mitre.org>,
	nfs@lists.sourceforge.net, capps@iozone.org
Subject: Re: 2.4.21 NFSv3 performance graph
Date: Sat, 29 Jan 2005 11:48:48 +0100	[thread overview]
Message-ID: <41FB6A10.6000001@int-evry.fr> (raw)
In-Reply-To: <1106329537.9849.68.camel@lade.trondhjem.org>

OK so now I run with your recommanded options and I get Output perfs as 
high as my network speed !! I am very surprised ! I don't think I am 
measuring NFS perfs here but network speed :-( .
Indeed for any couple filesize/record lenght I get wites result (see 
sample below) around 11000Kbytes/sec -> so if I am right -> 11MB/s -> or 
88Mbits/s ~= my 100Mbits ethernet througput ! (less ethernet/ip overhead !)

here's what I did:
$mount cobra3:/p2v5f3 /mnt/cobra3/ -o async,nfsvers=3
[root@arvouin /mnt/cobra3/iozone/arvouin]
$time iozone -a -c -e -i 0 -i 1 > arvouin-cobra3-i01-a-c-e.iozone

Command line used: iozone -a -c -e -i 0 -i 1
        Output is in Kbytes/sec
Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  
random    bkwd
record  stride
              KB  reclen   write rewrite    read    reread    read   
write    read rewrite    read   fwrite frewrite   fread  freread
            1024       4   10529   10603   409270   
408936                                           
            1024       8   10571   10666   472558   533076
....
            262144      64   11146   11156    11230    
11225                                            
            262144     128   11152   11172    11228    10948

here only read/reread changes as filesize increases , anyway 400/500MB/s 
reads is well over my 12.5 theorical ethernet througput, I suspect cache 
intervention here, no ? although I did put -e -c  options !

Any comment , advices ? what kind of result do you get for NFS writings 
with iozone ? as high as I get ? which options I am missing ?

Thanks. 

Trond Myklebust wrote:

>fr den 21.01.2005 Klokka 18:09 (+0100) skreiv Jehan PROCACCIA:
>  
>
>>more generaly, what tool do you recommand to bench NFS ?
>>I tried bonnie, bonnie++ and iozone.
>>for the latest here's the kind of command I ran (so that it doesn't 
>>takes hours to run the test!):
>>/opt/iozone/bin/iozone -p -s 10k -s 100k -s 1m -s 5m -s 10m -s 100m -i 
>>0  -i 1 -r 4 -r 64 -r 256 -r 512 -r 1024 -r 4096 -r8192 -r 16384 -c -U 
>>/mnt/cobra3 -f /mnt/cobra3/iozone.nagiostux > iozone-result
>>
>>My problem is that my NFS server has 4Go of ram, and bench programs 
>>always recommand to use filesize for tests higher than RAM size and even 
>>double size of the RAM so that it is not messuring cache activities !
>>    
>>
>
>For tests of reading, this is undoubtedly true. For tests of writing
>over NFS, this may be false: see the discussions of the iozone "-c" and
>"-e" flags below.
>
>Note that bonnie and bonnie++ lack the equivalent of the "-e", "-c"
>flags, and so are indeed not good for testing wire speeds unless you use
>very large files.
>
>  
>
>>Can you give me a sample of the iozone arguments you used ?
>>Any other tools ?
>>    
>>
>
>It depends on what I want to test 8-)
>
>
>Something like "iozone -c -a" should be fine for a basic test of the
>generic read/write code functionality.
>Note the "-c" which *is* usually necessary under NFS since any cached
>writes are going to be flushed to disk by the "close()" (or when the
>process exits). This means that close() will normally end up dominating
>your write timings for files < memory size.
>
>If you want to test mmap(), something like "iozone -e -B -a". I believe
>that "-e" should normally ensure that any writes are flushed to disk
>using the fsync() command, and that this is timed.
>Note that if you don't care about knowing how long it takes for the
>writes to be flushed to disk then you can drop the "-e": unlike ordinary
>read/write, mmap() does not guarantee that writes are flushed to disk
>after the file is closed.
>
>For direct IO, "iozone -I -a" suffices. Since direct IO is uncached, all
>write operations are synchronous, so "-c" and "-e" are unnecessary.
>
>
>Cheers,
>  Trond
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-01-29 15:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-14 19:00 2.4.21 NFSv3 performance graph Jeff Blaine
2005-01-14 23:59 ` Trond Myklebust
2005-01-18 14:54   ` Jeff Blaine
2005-01-18 17:08     ` Vincent Roqueta
2005-01-21 17:09   ` Jehan PROCACCIA
2005-01-21 17:45     ` Trond Myklebust
2005-01-29 10:48       ` jehan.procaccia [this message]
2005-01-29 17:25         ` Iozone
2005-01-30 11:33           ` jehan.procaccia
2005-02-17 13:54             ` jehan.procaccia
2005-02-17 15:44               ` Iozone
2005-02-17 17:27                 ` jehan.procaccia
2005-02-17 17:57                   ` Iozone
2005-02-17 16:00               ` J. Bruce Fields
2005-01-29 17:31         ` Iozone

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=41FB6A10.6000001@int-evry.fr \
    --to=jehan.procaccia@int-evry.fr \
    --cc=capps@iozone.org \
    --cc=jblaine@mitre.org \
    --cc=nfs@lists.sourceforge.net \
    --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.