Date: Tue, 18 Dec 2001 10:05:55 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Smirnov Konstantin <sam@rmp.ru> Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Tuning up FreeBSD - http://www.samag.com/documents/s=1147/sam0108q/ Message-ID: <Pine.NEB.3.96L.1011218095339.46449B-100000@fledge.watson.org> In-Reply-To: <16162204675.20011214114735@rmp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Dec 2001, Smirnov Konstantin wrote: > Hello all! > > Look what I've found in > http://www.samag.com/documents/s=1147/sam0108q/ > This is recomendation on tuning FreeBSD for higher perfomance when > it's used as the net server. And some of the things recommended are a bad idea, or already the default (and possibly both). :-) > ====================== cut ======================== > FreeBSD Tuning Tips > > The following FreeBSD OS tuning tips were suggested to us by readers of our article. > > In single-user mode: > > tunefs -n enable / > tunefs -n enable /usr > tunefs -n enable /var We need to make soft updates the default in -CURRENT; there was some disagreement on exactly the right mechanism, and what heuristic should be used to prevent application of SU to small root partitions. > Kernel modifications to make -- recompile and install the kernel afterwards: > MAXUSERS 512 This is no longer relevant: both -STABLE and -CURRENT will auto-tune the maxusers size by default based on available memory. For some environments, you may want to manually override to make the number bigger (or smaller). Many of the limits that used to be keyed to this are now tunable individually to much better effect, such as kern.maxfiles. tuning(7) is a much better guide right now due to being in sync with the system. > in /boot/load.conf > hw.ata.wc="1" In 4.4-RELEASE, the upcoming 4.5-RELEASE, and 4-STABLE in general, this is already the default. In 5.0, it is not the default, which is something we'll want to discuss more: we need to rely on safe drive behavior for background fsck. > kern.ipc.nmbclusters="60000" This is a patently bad idea on machines with <256Mb of memory, as each cluster represents about 2k of memory. In fact, tuning(7) specifically says not to do things like this: figure out how many you need. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16K receive and 16K send buffer, you need approximate 32MB worth of network buffers to deal with it. A good rule of thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768. So for this case you would want to set kern.ipc.nmbclusters to 32768. We recommend values between 1024 and 4096 for machines with moderates amount of memory, and between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter, it could lead to a boot-time crash. The -m option to netstat(1) may be used to observe network cluster use. Older versions of FreeBSD do not have this tunable and require that the kernel config(8) option NMBCLUSTERS be set instead. > in /etc/fstab > > Add to options for all hard disk file systems ",async": This is a very bad idea, as it will dramatically increase the possibility of serious system failure in the event of a crash or unexpected power loss. Not only that, but SU probably makes this irrelevent. > In /etc/sysctl.conf > vfs.vmiodirenable=1 This is now the default. > kern.ipc.maxsockbuf=2097152 > kern.ipc.somaxconn=8192 > kern.ipc.maxsockets=16424 These may result in resource exhaustion, and should be carefully balanced based on your machine's capacity and the desired load. > kern.maxfiles=65536 This may be a bad idea. I'm not sure what the person is tuning for, but these are generally pretty bad tuning instructions. They must have a ton of memory, or this system wouldn't even boot. > kern.maxfilesperproc=32768 > net.inet.tcp.rfc1323=1 Already the default. > net.inet.tcp.delayed_ack=0 The bug that required this will be fixed in 4.5-RELEASE. > net.inet.tcp.sendspace=65535 This may be a reasonable change in some environments, but I'm beginning to suspect that if these limits were all reached, even a maxed out i386 box couldn't provide enough memory to support them. > net.inet.tcp.recvspace=65535 Already the default. > net.inet.udp.recvspace=65535 I'm not sure this is a performance optimization. In fact, this may pessimize behavior in most network environments :-). > net.inet.udp.maxdgram=57344 > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 This may be useful in some environments, but also may not: what application do they have in mind? > What is your opinion? Is that parameters suitable for ALL systems? (I > think, no ;))) Maybe, somebody tried it yet? Many of these suggestions, if implemented, would result in substantial loss of system reliability and resilience to failure. In many cases, the default specified here would not even boot on most machines out there due to basic memory requirements. At least one fundamental concern is that some defaults here may pessimize performence for common applications: tuning of the system depends on the application, and as such choosing "big numbers" as a default is likely to hurt you far more than help. In 4.5-RELEASE, we've made an effort to substantially improve the default system tuning. About the only thing that hasn't been done for 4.5-RELEASE is to enable the softupdates on file systems by default: this is not something we should introduce prior to the release, due to its proximity. It's something that would be a reasonable default for 5.0-RELEASE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011218095339.46449B-100000>