From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 09:15:16 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 56E44106564A for ; Fri, 19 Dec 2008 09:15:16 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from fep5.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.freebsd.org (Postfix) with ESMTP id 28CE58FC0C for ; Fri, 19 Dec 2008 09:15:15 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from [192.168.1.126] (d150-251-98.home.cgocable.net [24.150.251.98]) by fep5.cogeco.net (Postfix) with ESMTP id 71EBA2D96 for ; Wed, 17 Dec 2008 14:13:38 -0500 (EST) Message-ID: <49494FE0.4040400@cogeco.ca> Date: Wed, 17 Dec 2008 14:15:44 -0500 From: Paul MacKenzie User-Agent: Thunderbird 3.0a1pre (Windows/2008022014) MIME-Version: 1.0 To: freebsd-stable@freebsd.org 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> <200812161556.mBGFuB7n089368@lava.sentex.ca> In-Reply-To: <200812161556.mBGFuB7n089368@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 19 Dec 2008 09:15:16 -0000 > 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 > I wondered if possibly my problem is related to this issue 104406? [ufs] Processes get stuck in "ufs" state under persistent CPU load http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= As the processes do get stuck in the ufs mode from what I can tell. I am going to be replacing the RAID card tomorrow to make sure it is not the card despite the lack of errors. If so I wondered if there was any way to quickly determine via programming which process is stuck and to get it unstuck as a temporary workaround? The problem reports mentions using 'kill -STOP' and continued with 'kill -CONT', which allows other processes to access the filesystem (until another such failure occurs). I just need to be able to determine which process is the one stuck in a relatively easy manner. Thanks, Paul