From owner-freebsd-questions@FreeBSD.ORG Thu Feb 16 21:33:31 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D99716A420 for ; Thu, 16 Feb 2006 21:33:31 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E0F43D45 for ; Thu, 16 Feb 2006 21:33:29 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.5/8.13.5/Debian-3) with ESMTP id k1GLX3nP023355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Feb 2006 23:33:04 +0200 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id k1GLWsvA002753; Thu, 16 Feb 2006 23:32:54 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id k1GLWsWW002752; Thu, 16 Feb 2006 23:32:54 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 16 Feb 2006 23:32:54 +0200 From: Giorgos Keramidas To: Mike Loiterman Message-ID: <20060216213253.GA2693@flame.pc> References: <20060216205715.GA2465@flame.pc> <022b01c6333e$8058ccd0$0401a8c0@Mike8500> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022b01c6333e$8058ccd0$0401a8c0@Mike8500> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.348, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.85, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr Cc: freebsd-questions@freebsd.org Subject: Re: Mysterious reboot X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 21:33:31 -0000 On 2006-02-16 15:18, Mike Loiterman wrote: >Giorgos Keramidas wrote: >> On 2006-02-16 14:32, Mike Loiterman wrote: >>> Wouter Spierenburg wrote: >>>> Try adding the following to /etc/sysctl.conf: >>>> >>>> kern.maxfiles=65535 >>>> kern.maxfilesperproc=20000 >>>> net.inet.tcp.delayed_ack=0 >>>> net.inet.ip.maxfragpackets=10 >>>> kern.ipc.somaxconn=2048 >>>> >>>> then 'cd' to /usr/src/sys/i386/conf >>>> cp GENERIC SERVER >>>> vi SERVER >>>> >>>> and add the following lines at the bottom of the file: options >>>> TCPDEBUG options RANDOM_IP_ID >>>> options TCP_DROP_SYNFIN >>>> options NMBCLUSTERS=65535 >>>> options NMBUFS=40960 >>>> [...] >> I'm not sure if the options are useful for your setup, so I'm >> not going to comment for or against them. > > Well, the server is an email/web server primarily. Not a huge > load, but I want to be hardened against DOS attacks...would > these help? kern.maxfiles and kern.masfilesperproc may need some tuning, but you would have to look at other related sysctls to be sure that you really need all those sizes, i.e.: # sysctl kern.openfiles will provide a measure of how many files your system keeps open. If this is too close to kern.maxfiles, you should definitely increase kern.maxfiles a bit, to be able to handle a bigger load. net.inet.tcp.delayed_ack may actually help for bulk transfers, by sending a smaller amount of packets for TCP acknowledgements. Reducing net.inet.ip.maxfragpackets so much will decrease the memory amount used for keeping around fragments of packets, but it also has the potential of increasing the number of fragments that are dropped & retransmitted. You should first look at: # sysctl net.inet.ip.fragpackets to see how many fragments your system usually keeps around. Increasing kern.ipc.somaxconn to 2048 will also require a bit more memory, for keeping the state of 'sockets pending a connection' around. But it will also decrease the amount of sockets that drop connections, potentially allowing more clients to connect at about the same time without having their connection being reset immediately. TCPDEBUG is not really a good option for a production machine, as it will probably slow things down a bit. RANDOM_IP_ID is more secure than not having it, but it also puts a bit more strain on the system by making frequent calls to the random IP id generator. TCP_DROP_SYNFIN has interesting comments in the `NOTES' files, so use it with care. NMBCLUSTERS and NMBUS can be probably optimized a bit, but first you should take a look at the statistics of: # netstat -m 258/387/645 mbufs in use (current/cache/total) 256/134/390/17024 mbuf clusters in use (current/cache/total/max) 576K/364K/941K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines If the 'current' values are very close to 'total' or 'max', you probably need to bump these a bit.