From owner-freebsd-stable@FreeBSD.ORG Thu May 3 18:23:54 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 9E79416A401; Thu, 3 May 2007 18:23:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7665813C44B; Thu, 3 May 2007 18:23:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1E2F046C97; Thu, 3 May 2007 14:23:54 -0400 (EDT) Date: Thu, 3 May 2007 19:23:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <366565EAE2F989935287015E@ganymede.hub.org> Message-ID: <20070503192139.C32808@fledge.watson.org> References: <366565EAE2F989935287015E@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: What triggers "No Buffer Space Available"? 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: Thu, 03 May 2007 18:23:54 -0000 On Tue, 1 May 2007, Marc G. Fournier wrote: > I'm still being hit by this one ... more frequently right now as I had to > move a bit more stuff *onto* that server ... I'm trying to figure out what I > can monitor for a 'leak' somewhere, but the only thing I'm able to find is > the whole nmbclusters stuff: > > mars# netstat -m | grep "mbuf clusters" > 130/542/672/25600 mbuf clusters in use (current/cache/total/max) > > the above is after 26hrs uptime ... > > Is there something else that will trigger/generate the above error message? ENOBUFS is a common error in the network stack reflecting a lack of free memory or exceeding a system, user, or process resource limit. While the classic source of ENOBUFS is mbuf or mbuf cluster exhaustion, there are several other sources of the error. For example, you will get ENOBUFS back if you run out of sockets, or a process tries to increase the size of socket buffers beyond the user resource limit. I'd look at all the output of netstat -m, not just clusters. I'd also look at kern.ipc.numopensockets and compare it to kern.ipc.maxsockets. Robert N M Watson Computer Laboratory University of Cambridge