Looking through the nfs-howto chapter 5 "Optimizing NFS Performance", I
found a few ambiguous statements and was wondering if I could get some
clarification.
There is a suggestion to increase rmem_default and rmem_max in
/proc/sys/net/core to "at least 256k". What is the limit on that? If I
have a server withs gobs of memory, how high can I increase that to still
get performance improvements. Are there some statistics I can use to
measure if increases in this are helping. Also, should I also increase
wmem_default and wmem_max. It makes no mention of that in the howto.
With respect to Overflow of fragmented packets, it mentions the 2.2
kernel, but never mentions the 2.4. Is it the same? If so, it might be
nice to clear that up in the howto. It also states that there is no ideal
value for this. Any suggestions for specific traffic patterns?
Thanks
--David Dougall
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Tom McNeal <[email protected]> writes:
> I also corrected the fragmentation part to refer to all
> kernels. The main thing to look for is MTU, plus the number of
> reassambly failures noted as "reasmfails" in /proc/net/snmp,
> especially when you start using 32K in udp (which is probably
> not the best idea).
Note that the number of reassembly failures is particularly inflated
if you are using a Linux client due to a bug in the socket layer: if
there is not enough buffer to send off all the fragments, then the
socket will still send off those fragments for which there is enough
space.
On the server side, this means that it will accumulate junk fragments
which never have a chance of being reassembled.
This 'feature' alone suffices to slow down the write speed to ~50% on
my test setup.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi -
I gleaned that tuning info from the SPECsfs and SPECweb99
benchmarks, and documented it on the Mission Critical Linux
servers that are still kept on line:
http://www.missioncriticallinux.com/orph/ServerNotes.pdf
The latest howtos, which have been getting updated over the
last few months, and are just about ready to go, contain an
updated discussion about [rw]mem_*, where I use the same examples,
but note that they apply to both read and write parameters.
As for limits, my paper notes much higher values than I was
really willing to state in the howto. Note that benchmarks are
often not real-world environments (I should probably remove the
"often" qualifier), so be sure to treat these suggestions with
a bit of skepticism.
I also corrected the fragmentation part to refer to all kernels.
The main thing to look for is MTU, plus the number of reassambly
failures noted as "reasmfails" in /proc/net/snmp, especially when
you start using 32K in udp (which is probably not the best idea).
Regards -
Tom
David Dougall wrote:
>
> Looking through the nfs-howto chapter 5 "Optimizing NFS Performance", I
> found a few ambiguous statements and was wondering if I could get some
> clarification.
> There is a suggestion to increase rmem_default and rmem_max in
> /proc/sys/net/core to "at least 256k". What is the limit on that? If I
> have a server withs gobs of memory, how high can I increase that to still
> get performance improvements. Are there some statistics I can use to
> measure if increases in this are helping. Also, should I also increase
> wmem_default and wmem_max. It makes no mention of that in the howto.
>
> With respect to Overflow of fragmented packets, it mentions the 2.2
> kernel, but never mentions the 2.4. Is it the same? If so, it might be
> nice to clear that up in the howto. It also states that there is no ideal
> value for this. Any suggestions for specific traffic patterns?
>
> Thanks
> --David Dougall
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Two, two, TWO treats in one.
> http://thinkgeek.com/sf
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
--
------------------------------------------------------------
Tom McNeal [email protected] (650)906-0761 (cell)
------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs