From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 10:57:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B397CEC for ; Fri, 25 Jul 2014 10:57:59 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D00A62216 for ; Fri, 25 Jul 2014 10:57:58 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6PAvtB7070083; Fri, 25 Jul 2014 12:57:55 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 45EB5378B; Fri, 25 Jul 2014 12:57:55 +0200 (CEST) Message-ID: <53D23832.6090000@omnilan.de> Date: Fri, 25 Jul 2014 12:57:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca> In-Reply-To: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig25BC1A0F8CB122F4411BA2E1" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 25 Jul 2014 12:57:55 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 10:57:59 -0000 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--