From owner-freebsd-questions@FreeBSD.ORG Fri Mar 12 08:02:47 2004 Return-Path: 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 E013116A4CE for ; Fri, 12 Mar 2004 08:02:47 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 726E643D2F for ; Fri, 12 Mar 2004 08:02:47 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i2CG2kMa013492; Fri, 12 Mar 2004 10:02:46 -0600 (CST) (envelope-from dan) Date: Fri, 12 Mar 2004 10:02:46 -0600 From: Dan Nelson To: Jimmy Olgeni Message-ID: <20040312160246.GB37035@dan.emsphone.com> References: <20040312153634.O80001@dev1.localdomain.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040312153634.O80001@dev1.localdomain.net> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-questions@freebsd.org Subject: Re: about the "wdrain" state X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2004 16:02:48 -0000 In the last episode (Mar 12), Jimmy Olgeni said: > When I move a lot of data on the disk (like untarring a new ports > collection or /usr/src/) the process works fine for a while, then > takes a long pause, then restarts again. When it "pauses", pressing > ^T shows it's in the "wdrain" state, which looks related to waiting > for the disk to finish some write operations. Unfortunately, the 5i > controller has a somewhat poor performance by itself so that may be > the cause. > > Are there any kernel tunables that I could change to at least > "spread" the pauses over many small intervals, rather than locking > the process for a few seconds? The volume is using softupdates, I > thought about changing kern.filedelay and friends but I'd like to > know if there are sensibile values to put in before I fry the > production server :) Depending on how much memory you have, I think raising vfs.hirunningspace might help here. It will allow more write buffers to build up before the system decides it needs to flush some. Take a look at the waitrunningbufspace() function in /sys/kern/vfs_bio.c, or do a web search for "hirunningspace" -- Dan Nelson dnelson@allantgroup.com