From: "work-usenet@nouce.net" <work-usenet@nouce.net>
To: nfs@lists.sourceforge.net
Subject: Questiong regarding change in support for > 256 outstanding read/write operations per mount point for linux clients
Date: Wed, 09 Jun 2004 09:10:41 -0400 [thread overview]
Message-ID: <40C70C50.7030105@nouce.net> (raw)
*Is there a backpatch to allow this change in a 2.4 kernel and/or has
this been added to the 2.6 client? As I use NFS on 2.4 based Linux
systems. But would like to see if this client change would help
performance problems I'm seeing with clients connecting to an Netapp
filer. Thanks.
B7. I have achieved pretty fast speeds in some client benchmarks, but
when my client is heavily loaded, it slows down considerably. Why does
that happen? *
*A.* The Linux client limits the total number of pending read or
write operations per mount point. This prevents the client from
exhausting its memory with cached read or write requests when the
network or server is slow. The hard limit is 256 outstanding read or
write operations per mount point. When that limit is reached, the
client does not issue a new read or write operation until at least
one outstanding read or write operation completes, thus serializing
all reads and writes on that mount point until load is reduced.
Two ways of mitigating this effect are to:
1.
Increase rsize and wsize on your client's mount points. This
increases the amount of data that can be involved in
outstanding reads or writes at any given time.
2.
Mount the same server partition multiple times on your
clients, and spread your applications among the mount points.
This limit has been removed in the 2.5 NFS client (after 2.5.47).
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2004-06-09 13:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-09 13:10 work-usenet [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-09 14:08 Questiong regarding change in support for > 256 outstanding read/write operations per mount point for linux clients Lever, Charles
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=40C70C50.7030105@nouce.net \
--to=work-usenet@nouce.net \
--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.