Date: Mon, 24 Apr 2006 13:53:22 +0300 From: "Vlad GALU" <vladgalu@gmail.com> To: freebsd-net@freebsd.org Subject: Re: requests for mbufs denied Message-ID: <79722fad0604240353x6b7d38feoc7dccc7b8662c486@mail.gmail.com> In-Reply-To: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> References: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/24/06, Vlad GALU <vladgalu@gmail.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79722fad0604240353x6b7d38feoc7dccc7b8662c486>