From owner-freebsd-stable@FreeBSD.ORG Mon Jan 8 09:22:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A63216A4CA for ; Mon, 8 Jan 2007 09:22:18 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id AFE0413C4B6 for ; Mon, 8 Jan 2007 09:22:15 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so5502112uge for ; Mon, 08 Jan 2007 01:22:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mJiluOIfwMhV3xhBBILFvxsKkGhD74LQJTZxqVJjksLuq8SO9Dnyei12fJezEFbhvu8/uT+TOT99z4U4WU/YfNDRpw9IqnvlIg6tlWnLJT8JCnzxRcKFKjlR4ikkC+EnTp53QNZkPAM69z2HeNoQJ00mhNCrYiHQI2j9ZhEcGpA= Received: by 10.66.216.1 with SMTP id o1mr33133266ugg.1168248134250; Mon, 08 Jan 2007 01:22:14 -0800 (PST) Received: by 10.66.255.10 with HTTP; Mon, 8 Jan 2007 01:22:14 -0800 (PST) Message-ID: <499c70c0701080122y665a3efdub465907ab89d15ba@mail.gmail.com> Date: Mon, 8 Jan 2007 12:22:14 +0300 From: "Abdullah Al-Marrie" To: "Thomas Herrlin" In-Reply-To: <4593DC34.2030308@atlantis.maniacs.se> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1167247246.96863.23.camel@opus.cse.buffalo.edu> <4593DC34.2030308@atlantis.maniacs.se> Cc: peter@holm.cc, freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.2-RC2 Available - networking zoneli freeze problem still exist. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2007 09:22:18 -0000 On 12/28/06, Thomas Herrlin wrote: > Ken Smith wrote: > > > > All problems we felt needed to be addressed before 6.2 could be released > > have been taken care of. > It still runs networking daemons into a frozen zoneli state on > heavy/(D)DOS network loads. Such processes cant be kill-9ed so there is > no way to recover from it. (think frozen sshd and a very remote/headless > server). > See the stress test panic called 'Ran out of "128 Bucket" > ' on the 6.2 > todo list and my own latest test here: > http://www.maniacs.se/~junics/temp/vmstat-z.txt > This test was on a new 6.2-RC2 install with no zone limit tweaks nor any > sbsize limits in /etc/login.conf. > I just made a vm disk image with replication instructions, however Peter > Holm have replicated it with his own tools so i have not bothered with > it until now. > > > Unless further testing turns up something new > > RC2, which is available now for dowloading, will be the last of the > > Release Candidates and 6.2-RELEASE should be ready in about 2 weeks. > > Your continued help with testing would be greatly appreciated. If you > > notice any problems with RC2 you can submit a PR or send mail to this > > list. > > > > > /Thomas Herrlin Have you tried these options in kernel? options DEVICE_POLLING options HZ=1000 add this line to the end of your /etc/sysctl.conf: kern.polling.enable=1 DEVICE_POLLING changes the method through which data gets from your network card to the kernel. Traditionally, each time the network card needs attention (for example when it receives a packet), it generates an interrupt request. The request causes a context switch and a call to an interrupt handler. A context switch is when the CPU and kernel have to switch from user land (the user's programs or daemons), and kernel land (dealing with device drivers, hardware, and other kernel-bound tasks). The last few years have seen significant improvements in the efficiency of context switching but it is still an extremely expensive operation. Furthermore, the amount of time the system can have to spend when dealing with an interrupt can be almost limitless. It is completely possible for an interrupt to never free the kernel, leaving your machine unresponsive. Those of us unfortunate enough to be on the wrong side of certain Denial of Service attacks will know about this. More info in here A guide to server and workstation optimization, by Avleen Vig http://silverwraith.com/papers/freebsd-tuning.php -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/