requests for mbufs denied

Peter Blok pblok at bsd4all.org
Tue Apr 25 14:33:35 UTC 2006


Hi,

I have tried to debug this and it turns out that it is not an allocation
failure at all. It happens as part of uma_reclaim, which will eventually
call uma_zfree_internal which increments the counters.

When I use the following patch, uma_reclaim will skip uma_zfree_internal for
both mbuf and mcluster zones. It is my first impression that the size of the
two zones are static anyway. I am not sure this is a correct fix, but it
works in my case pending further investigation.

--- sys/kern/kern_mbuf.c.orig   Sun Apr  9 13:32:51 2006
+++ sys/kern/kern_mbuf.c        Sun Apr  9 13:33:19 2006
@@ -168,7 +168,7 @@
 #else
            NULL, NULL,
 #endif
-           MSIZE - 1, UMA_ZONE_MAXBUCKET);
+           MSIZE - 1, UMA_ZONE_MAXBUCKET|UMA_ZONE_NOFREE);

        zone_clust = uma_zcreate(MBUF_CLUSTER_MEM_NAME, MCLBYTES,
            mb_ctor_clust, mb_dtor_clust,
@@ -177,7 +177,7 @@
 #else
            NULL, NULL,
 #endif
-           UMA_ALIGN_PTR, UMA_ZONE_REFCNT);
+           UMA_ALIGN_PTR, UMA_ZONE_REFCNT|UMA_ZONE_NOFREE);

        if (nmbclusters > 0)
                uma_zone_set_max(zone_clust, nmbclusters);
~

-----Original Message-----
From: owner-freebsd-net at freebsd.org [mailto:owner-freebsd-net at freebsd.org]
On Behalf Of Vlad GALU
Sent: Monday, April 24, 2006 12:51 PM
To: freebsd-net at freebsd.org
Subject: requests for mbufs denied

    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.

--
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.
_______________________________________________
freebsd-net at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"




More information about the freebsd-net mailing list