From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 13:30:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE5FE37B401 for ; Fri, 1 Aug 2003 13:30:37 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id EC8DF43FBF for ; Fri, 1 Aug 2003 13:30:36 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 9320 invoked from network); 1 Aug 2003 20:30:34 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 Aug 2003 20:30:34 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 1 Aug 2003 15:28:35 -0500 (CDT) From: Mike Silbersack To: Steve Francis In-Reply-To: <3F2AC3F5.3010804@expertcity.com> Message-ID: <20030801152510.J2165@odysseus.silby.com> References: <3F2AC3F5.3010804@expertcity.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: mbuf clusters exhausted w/o reaching max? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2003 20:30:38 -0000 On Fri, 1 Aug 2003, Steve Francis wrote: > I have a FreeBSD 4.8-RELEASE #5 system that reported: > Aug 1 11:50:39 rack2-101 /kernel: All mbuf clusters exhausted, please see tuning(7). > Aug 1 11:50:39 rack2-101 /kernel: All mbufs exhausted, please see tuning(7). > > Yet its not close to the max allowed for clusters. > rack2-101.nyc# netstat -m > 1338/4240/131072 mbufs in use (current/peak/max): > 1338 mbufs allocated to data > 709/3366/32768 mbuf clusters in use (current/peak/max) > 7792 Kbytes allocated to network (7% of mb_map in use) > 50 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > rack2-101.nyc# Mbufs & mbuf clusters are allocated from the kernel map, so it's possible for allocations to fail due to the kernel map being relatively full due to other parts of the kernel eating memory. This is probably what's happening in your case; given that only 50 allocations were denied, it probably didn't hurt your system much. Note that the kernel map is not the size of all ram; it's usually only 1/4 of the amount of ram available, with a ceiling of 256MB. You could try playing with those parameters, but you'll probably end up causing other problems in the process. :) (Fair kernel memory management is an area we're still working on in -current.) Mike "Silby" Silbersack