Date: Mon, 13 Dec 1999 08:39:18 -0800 (PST) From: Doug White <dwhite@resnet.uoregon.edu> To: Bosko Milekic <bmilekic@dsuper.net> Cc: David Greenman <dg@root.com>, Tom <tom@uniserve.com>, Greg Prosser <greg@snickers.org>, freebsd <freebsd-stable@FreeBSD.ORG> Subject: Re: SYN Hardening patches? / SYN Code in 3.4-RC Message-ID: <Pine.BSF.4.21.9912130834160.74623-100000@resnet.uoregon.edu> In-Reply-To: <Pine.OSF.4.05.9912122042160.27003-100000@oracle.dsuper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Dec 1999, Bosko Milekic wrote: > Even at that, MAXUSERS still contributes to the mb_map size. I see > your point, though, in the sense that by setting up NMBCLUSTERS, the > overall size of mb_map will be affected by that setting, and not > MAXUSERS, in general. > So here's the question: Why not remove MAXUSERS' influence over the > size of the mb_map, and just have it influenced by a single option? Because it doesn't make sense to separate it out? maxusers is a good general sizing knob; it should size everything that's related to server capacity. You should override the maxuser-based calculations IFF you know the calculated number isn't enough, even at maxusers 128. We have hard-core MDAs that get a 'options NMBCLUSTERS=16384' and 'maxusers 128' based on real-world statistics. These machines routinely peak out at 10K mbuf clusters and 22MBytes of network memory. With the default settings they wouldn't last 10 minutes. And even with 16K mbufs they still die when large parts of the Net go away. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9912130834160.74623-100000>