From owner-freebsd-stable@FreeBSD.ORG Tue Dec 16 15:56:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE621065679 for ; Tue, 16 Dec 2008 15:56:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B38AA8FC26 for ; Tue, 16 Dec 2008 15:56:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBGFuBQq010388; Tue, 16 Dec 2008 10:56:11 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBGFuB7n089368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:56:11 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812161556.mBGFuB7n089368@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Dec 2008 10:56:19 -0500 To: Paul MacKenzie , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <4946DA2F.7090508@cogeco.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> <200812152035.mBFKZkj4084689@lava.sentex.ca> <4946DA2F.7090508@cogeco.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: 7.1-PRERELEASE: arcmsr write performance problem 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: Tue, 16 Dec 2008 15:56:14 -0000 At 05:29 PM 12/15/2008, Paul MacKenzie wrote: >The next thing I am doing is going to be removing the QUOTA feature >to see if this has any bearing >on this problem. It does not appear to be even writing at a heavy >load as you can see (almost >nothing) but the processes are mostly in UFS when it spirals out of control. Whats strange is that the output from gstat shows the disks hardly active at all.... Yet why is the syncer at 100% ? Do you have write caching disabled on the array ? What does the raw throughput look like to the disks ? e.g. if you try a simple dd if=/dev/zero of=/var/tmp bs=1024k count=1000 ? >I moved the processing of amavisd-new into a memory drive to at >least take that off the IO and this >seems to have helped a bit. There is not a lot of mail going through >the system but every little bit >helps. I suspect this is one other reason that is bringing the >problem to the forefront as >amavisd-new can use the disks a bit to process each e-mail. Is the high load average simply a function of processes blocking on network io ? On our av/spam scanners for example show a high load avg because there are many processes waiting on network io to complete (e.g. talking to RBL lists, waiting for DCC servers to complete etc) Also, is it really related to the arcmsr driver ? i.e. if you did the same tasks on a single IDE drive, is the performance profile going to be the same ? ---Mike