Date: Fri, 25 Jul 2014 12:57:54 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel Message-ID: <53D23832.6090000@omnilan.de> In-Reply-To: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca> References: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig25BC1A0F8CB122F4411BA2E1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 12:32 (localtime)= : > =E2=80=A6 >> 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 mayb= e) > 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 decad= e=E2=80=A6 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 --------------enig25BC1A0F8CB122F4411BA2E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPSODIACgkQLDqVQ9VXb8jLNQCfW3sg2ZiEUGHJzL1bxv/ndtFj mtAAoJXK360tQa3D/xAs84X3SIOn1dl4 =0/a4 -----END PGP SIGNATURE----- --------------enig25BC1A0F8CB122F4411BA2E1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53D23832.6090000>