requests for mbufs denied

[Vlad GALU]

On 4/24/06, Vlad GALU <vladgalu at 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.