From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Miquel van Smoorenburg <miquels@cistron.nl>,
Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
linuxram@us.ibm.com
Cc: linux-kernel@vger.kernel.org
Subject: Slowwwwwwwwwwww NFS read performance....
Date: Thu, 15 Jan 2004 14:00:56 -0500 [thread overview]
Message-ID: <1074193256.2148.55.camel@nidelv.trondhjem.org> (raw)
In-Reply-To: <1074134135.1522.52.camel@nidelv.trondhjem.org>
På on , 14/01/2004 klokka 21:35, skreiv Trond Myklebust:
> Err.. no...
>
> I didn't have a 2.6.1-mm3 machine ready to go in our GigE testbed (I'm
> busy compiling one up right now). However I did run a quick test on
> 2.6.0-test11. Iozone rather than bonnie, but the results should be
> comparable:
Hah.... They turned out not to be...
The changeset with key
akpm@osdl.org[torvalds]|ChangeSet|20031230234945|63435
# ChangeSet
# 2003/12/30 15:49:45-08:00 akpm@osdl.org
# [PATCH] readahead: multiple performance fixes
#
# From: Ram Pai <linuxram@us.ibm.com>
Has a devastating effect on NFS readahead. Using iozone in sequential
read mode, I get a 90% drop in performance on my GigE against a fast
NetApp filer. See the following test results.
Cheers,
Trond
------------------------
Iozone: Performance Test of File I/O
Version $Revision: 3.169 $
Compiled for 32 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million,
Jean-Marc Zucconi, Jeff Blomberg.
Run began: Thu Jan 15 13:38:42 2004
Include close in write timing
File size set to 2097152 KB
Record Size 128 KB
Command line used: /plymouth/trondmy/public/programs/fs/iozone -c -t1 -s 2048m -r 128k -i0 -i1
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 1 process
Each process writes a 2097152 Kbyte file in 128 Kbyte records
Children see throughput for 1 initial writers = 107477.06 KB/sec
Parent sees throughput for 1 initial writers = 107469.93 KB/sec
Min throughput per process = 107477.06 KB/sec
Max throughput per process = 107477.06 KB/sec
Avg throughput per process = 107477.06 KB/sec
Min xfer = 2097152.00 KB
Children see throughput for 1 rewriters = 108333.84 KB/sec
Parent sees throughput for 1 rewriters = 108326.78 KB/sec
Min throughput per process = 108333.84 KB/sec
Max throughput per process = 108333.84 KB/sec
Avg throughput per process = 108333.84 KB/sec
Min xfer = 2097152.00 KB
Children see throughput for 1 readers = 39179.22 KB/sec
Parent sees throughput for 1 readers = 39178.28 KB/sec
Min throughput per process = 39179.22 KB/sec
Max throughput per process = 39179.22 KB/sec
Avg throughput per process = 39179.22 KB/sec
Min xfer = 2097152.00 KB
Children see throughput for 1 re-readers = 14926.65 KB/sec
Parent sees throughput for 1 re-readers = 14926.62 KB/sec
Min throughput per process = 14926.65 KB/sec
Max throughput per process = 14926.65 KB/sec
Avg throughput per process = 14926.65 KB/sec
Min xfer = 2097152.00 KB
-------------------------------------------------------------------------------
If I remove just that one patch, then read performance is back to what
is expected:
Iozone: Performance Test of File I/O
Version $Revision: 3.169 $
Compiled for 32 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million,
Jean-Marc Zucconi, Jeff Blomberg.
Run began: Thu Jan 15 13:57:51 2004
Include close in write timing
File size set to 2097152 KB
Record Size 128 KB
Command line used: /plymouth/trondmy/public/programs/fs/iozone -c -t1 -s 2048m -r 128k -i0 -i1
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 1 process
Each process writes a 2097152 Kbyte file in 128 Kbyte records
Children see throughput for 1 initial writers = 109917.64 KB/sec
Parent sees throughput for 1 initial writers = 109915.87 KB/sec
Min throughput per process = 109917.64 KB/sec
Max throughput per process = 109917.64 KB/sec
Avg throughput per process = 109917.64 KB/sec
Min xfer = 2097152.00 KB
Children see throughput for 1 rewriters = 110838.23 KB/sec
Parent sees throughput for 1 rewriters = 110830.83 KB/sec
Min throughput per process = 110838.23 KB/sec
Max throughput per process = 110838.23 KB/sec
Avg throughput per process = 110838.23 KB/sec
Min xfer = 2097152.00 KB
Children see throughput for 1 readers = 146490.67 KB/sec
Parent sees throughput for 1 readers = 146487.63 KB/sec
Min throughput per process = 146490.67 KB/sec
Max throughput per process = 146490.67 KB/sec
Avg throughput per process = 146490.67 KB/sec
Min xfer = 2097152.00 KB
Children see throughput for 1 re-readers = 163164.72 KB/sec
Parent sees throughput for 1 re-readers = 163148.56 KB/sec
Min throughput per process = 163164.72 KB/sec
Max throughput per process = 163164.72 KB/sec
Avg throughput per process = 163164.72 KB/sec
Min xfer = 2097152.00 KB
Cheers,
Trond
next prev parent reply other threads:[~2004-01-15 19:01 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-06 0:46 2.6.0 NFS-server low to 0 performance Guennadi Liakhovetski
2004-01-07 13:36 ` Guennadi Liakhovetski
2004-01-07 22:30 ` bill davidsen
2004-01-08 12:48 ` Guennadi Liakhovetski
2004-01-07 17:49 ` Mike Fedyk
2004-01-07 18:13 ` Guennadi Liakhovetski
2004-01-07 18:19 ` Mike Fedyk
2004-01-07 19:06 ` Guennadi Liakhovetski
2004-01-09 10:08 ` Guennadi Liakhovetski
2004-01-09 18:00 ` Mike Fedyk
2004-01-10 0:38 ` Guennadi Liakhovetski
2004-01-10 1:38 ` Mike Fedyk
2004-01-10 11:10 ` Guennadi Liakhovetski
2004-01-10 14:30 ` Trond Myklebust
2004-01-10 20:04 ` Guennadi Liakhovetski
2004-01-10 21:57 ` Trond Myklebust
2004-01-10 22:14 ` Mike Fedyk
2004-01-10 22:47 ` Trond Myklebust
2004-01-10 22:42 ` Guennadi Liakhovetski
2004-01-10 22:51 ` Jesper Juhl
2004-01-11 13:18 ` Helge Hafting
2004-01-11 13:53 ` Russell King
2004-01-11 14:24 ` Guennadi Liakhovetski
2004-01-15 11:38 ` Pavel Machek
2004-01-12 5:06 ` Bill Davidsen
2004-01-12 14:27 ` Trond Myklebust
2004-01-12 15:12 ` Trond Myklebust
2004-01-16 5:44 ` Mike Fedyk
2004-01-16 6:05 ` Trond Myklebust
2004-01-16 6:53 ` Mike Fedyk
2004-01-10 22:34 ` Mike Fedyk
2004-01-10 22:52 ` Guennadi Liakhovetski
2004-01-10 22:57 ` Mike Fedyk
2004-01-10 23:00 ` Guennadi Liakhovetski
2004-01-08 21:42 ` Pavel Machek
2004-01-12 23:18 ` Guennadi Liakhovetski
2004-01-12 23:28 ` Jesper Juhl
2004-01-13 0:39 ` Pavel Machek
2004-01-14 3:00 ` Daniel Roesen
2004-01-14 18:16 ` Guennadi Liakhovetski
2004-01-13 1:55 ` Slow NFS performance over wireless! Roman Gaufman
2004-01-13 2:15 ` Trond Myklebust
2004-01-13 20:25 ` Joshua M. Thompson
2004-01-13 20:45 ` Trond Myklebust
2004-01-15 1:12 ` Miquel van Smoorenburg
[not found] ` <20040115013312.GO1594@srv-lnx2600.matchmail.com>
2004-01-15 2:04 ` Miquel van Smoorenburg
2004-01-15 2:35 ` Trond Myklebust
2004-01-15 19:00 ` Trond Myklebust [this message]
2004-01-15 19:53 ` Slowwwwwwwwwwww NFS read performance Ram Pai
2004-01-15 20:16 ` Trond Myklebust
2004-01-15 20:54 ` Trond Myklebust
2004-01-18 6:04 ` Greg Fitzgerald
2004-01-18 17:55 ` Mike Fedyk
2004-01-16 0:52 ` Slow NFS performance [was: over wireless!] Miquel van Smoorenburg
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=1074193256.2148.55.camel@nidelv.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=miquels@cistron.nl \
--cc=torvalds@osdl.org \
/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
all inboxes | Powered by JetHome®