From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 10:53:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0F3AD16A401 for ; Mon, 24 Apr 2006 10:53:30 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDF043D73 for ; Mon, 24 Apr 2006 10:53:23 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so975734pyc for ; Mon, 24 Apr 2006 03:53:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jncqpp9NfoPQFz86r5fsmG3P87Wa4iG5Rsd91LgJuftajsglNEcBzqSsSkzbKx4OOmTrPva6by0AVFPJrsmblFsO0FSnQcZT1n78obunnpsY0MDTB/H0b7fA3laj/STkPzxTy5GWvuhW1FdUShj731NDHckgAbgAYbaCOhtdpRk= Received: by 10.35.66.12 with SMTP id t12mr792905pyk; Mon, 24 Apr 2006 03:53:22 -0700 (PDT) Received: by 10.35.38.9 with HTTP; Mon, 24 Apr 2006 03:53:22 -0700 (PDT) Message-ID: <79722fad0604240353x6b7d38feoc7dccc7b8662c486@mail.gmail.com> Date: Mon, 24 Apr 2006 13:53:22 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org In-Reply-To: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> Subject: Re: requests for mbufs denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 10:53:30 -0000 On 4/24/06, Vlad GALU wrote: > The machine in question is a 6.1-RC. It serves a quite big number > of clients (the lowest concurrency figures are around 2000, with peaks > up to 9000). The in/out buffers for tcp sockets are 8K each. > kern.ipc.nmbclusters is set to 327680. The firewall is pf, with the > following limits: 131072 states and 262144 src-nodes. So more than > generous limits. However, $subj statistics keep growing and growing. > The machine has rebooted a few times, without dumping any core upon > restart, although debugging support (both symbols and kgdb) is > compiled in. > Should I worry about the aforementioned stats ? If so, any idea of > how to narrow the issue down ? I can't test much on the machine, > unfortunately. > > P.S. I've the feeling that the growth rate of allocation failures went > downhill since I removed the pfsync support, but it's just a feeling, > I didn't measure it accurately. > As a secondary footnote, the statistics for the currenty used mbuf are never alarming, while the number of allocation request still grows: -- cut here -- 761/2314/3075 mbufs in use (current/cache/total) 406/568/974/327680 mbuf clusters in use (current/cache/total/max) [...] 1004K/1714K/2719K bytes allocated to network (current/cache/total) 273341/8477/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) -- and here -- > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.