From: Matthew Mitchell <matthew@geodev.com>
To: nfs@lists.sourceforge.net
Subject: mmap() and NFS server performance
Date: Fri, 13 Dec 2002 15:09:46 -0600 [thread overview]
Message-ID: <3DFA4C9A.50101@geodev.com> (raw)
Hello,
We've noticed some interesting behavior regarding mmap file IO and were
wondering if anyone here had some clues as to what might be going on.
We have some applications that mmap() files into memory for the purpose
of updating some potentially scattered word-sized data values. These
apps were originally written on Solaris with Solaris NFS servers assumed
to be the data source; the Sun guys said that mmap would be much faster
than read/write and they were correct. However, now that we have a few
Linux NFS servers, we're seeing the opposite.
It takes, for example, 20-24 hours to update a 2GB file (there are on
the order of 1M words to update) via mmap, whereas reading in the whole
file, updating it in memory, and writing it out again takes about 30
minutes (limited by network speed in our case). This when the file
resides on the Linux server. On Solaris the mmap update runs on the
order of 15-20 minutes. Client in both cases is a Solaris 8 machine.
What we are speculating is that the Solaris NFS server is "cheating" by
keeping file state information between NFS reads and writes. (The
updates do occur in sequence.) Are there any heuristics or
optimizations done by the Linux NFS server that might help the
performance here?
All things, alas, are not equal in this comparison -- the Solaris server
in question is an 8 CPU Enterprise 4500 with 8GB of RAM, and the Linux
server is a single-processor P4 with 512MB of RAM. The Solaris server
is much busier than the Linux server, though (I know it cannot be
caching the whole file in memory). The Linux server is running Red
Hat's 2.4.18-14 kernel.
Anyone have any ideas as to why this is happening and what, if anything,
we can do to speed up the mmap IO when using the Linux server?
--
Matthew Mitchell
Systems Programmer/Administrator matthew@geodev.com
Geophysical Development Corporation phone 713 782 1234
1 Riverway Suite 2100, Houston, TX 77056 fax 713 782 1829
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2002-12-13 21:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-13 21:09 Matthew Mitchell [this message]
2002-12-13 21:35 ` mmap() and NFS server performance Brian Pawlowski
2002-12-14 11:22 ` Trond Myklebust
2002-12-16 14:33 ` Matthew Mitchell
2002-12-16 14:50 ` Trond Myklebust
2002-12-16 20:04 ` Matthew Mitchell
2002-12-14 16:51 ` David B. Ritch
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=3DFA4C9A.50101@geodev.com \
--to=matthew@geodev.com \
--cc=nfs@lists.sourceforge.net \
/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.