nfsd server cache flooded, try to increase nfsrc_floodlevel

[Harald Schmalzbauer]

 Bezüglich Rick Macklem's Nachricht vom 25.07.2014 12:32 (localtime):
> …
>> environment forces me to reboot the storage server every 2nd day.
>> IMHO such a setup shouldn't require manual tuning and I consider this
>> as
>> a really urgent problem!
> Well, the default was what worked for the hardware I have to test on:
> - single core i386 server with 256Mbytes of memory on 100Mbps network
>
> Since I have nothing close to 10Gbps networking (100Mbps only), I can't
> test even a situation like your server/single client, so all I can do
> is set a default that works for me.
>
> I don't think you can expect a "one size fits all" setting when you
> have servers ranging from what I have (i386 with 256Mbytes of memory)

Very nice to have the possibillity to run an NFS server of this size! I
really appreciate keeping minimalistic requirements in mind!


> to 64 cores, Gbytes of RAM etc. Eventually, others (like iXsystems maybe)
> who can test on a range of servers may be able to come up with a way to
> tune it dynamically based on server size, but that requires a range of
> hardware to test on.
>
> Basically, although NFSv4 is now 10years old, people are just starting
> to use it, so experience is still pretty limited w.r.t. it.

I'm exactly one of this late adopters. But only because building
reliable network services had forced me to avoid nfs for almost one decade…

I absolutely understand that one-fits-all doesn't play well here, but a
production quality nfsserver implementation must'nt completely lock up
becuase of cache measurements on any common setup.
I guess having 1GbE is absolutely common for people setting up
FreeBSD-9.3. I'm noughty enough to state that 100mbit/s and 256MB RAM is
a special case these days! Especially in production environment. And
that's what the -Releases should be good for.

So, please let's try to make sure that this nfsrc_floodlevel lockup
doesn't hit users next -Release again! (and I'm not the only one who
reported this problem)
If this requires altering sysctl-values, please alter them even if
throughput suffers or minmum requirements increase. Anything is better
than a locked service which needs rebooting!

Again, I'd like to ask if there are reasons known not to use the
noopen.patch (http://people.freebsd.org/~rmacklem/noopen.patch)?

Thanks,

-Harry


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140725/c43e2ee0/attachment.sig>