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