*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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
it's pretty simple to boost the 256 page limit by changing the #define
constant right at the top of nfs_flushd.h.
but backporting is an architectural change and requires particular
kernel features which may not exist, or don't have the same
functionality in 2.4, thus it would be difficult to backport (yes, i've
tried).
there are also political issues: marcelo & trond are not taking any
significant changes for the stock 2.4 code base any longer. RH will not
take any changes that may break their ABI compatibility. so the change
would almost certainly be a source code patch and would not likely be
supported by anyone.
finally, there are other limits and bugs in 2.4 that your customers may
be hitting instead. one example is the limit on the size of the RPC
slot table.
if there is a performance issue with our filers, consider having the
customers open a case with netapp so that we can engage our NFS and
Linux client expertise to help.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, June 09, 2004 9:11 AM
> To: [email protected]
> Subject: [NFS] Questiong regarding change in support for >
> 256 outstanding read/write operations per mount point for
> linux clients
>
>
> *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 - [email protected]
> https://lists.sourceforge.net/lists/listinfo/n> fs
>