From owner-freebsd-stable@FreeBSD.ORG Mon Jun 26 12:22:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB43616A401 for ; Mon, 26 Jun 2006 12:22:54 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8212743D70 for ; Mon, 26 Jun 2006 12:22:54 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id B650F5DBA; Mon, 26 Jun 2006 08:22:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOAbZk87kCgT; Mon, 26 Jun 2006 08:22:52 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-201-170.ny325.east.verizon.net [68.160.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 97E6C5DA7; Mon, 26 Jun 2006 08:22:52 -0400 (EDT) Message-ID: <449FD196.1020405@mac.com> Date: Mon, 26 Jun 2006 08:22:46 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Marc G. Fournier" References: <20060626080344.X1114@ganymede.hub.org> <20060626082906.T1114@ganymede.hub.org> In-Reply-To: <20060626082906.T1114@ganymede.hub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: leaking blocked processes in vmstat ... how to debug? 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, 26 Jun 2006 12:22:55 -0000 Marc G. Fournier wrote: > Up to 48 right now, and still nothing to show for it ... Perhaps it is not clear to you that under Unix is it normal for processes to block waiting on events like user input, a signal indicating a timer has fired or a pipe has more data, etc. The reason you are looking for processes stuck in "D" for "Disk wait" state is to identify any large processes that are being swapped out and thus being held up by RAM limitations. On the other hand, it's entirely possible that you've simply got too much stuff running for the available hardware, and will need to either add RAM or offload some of the workload to other machines. -- -Chuck