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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Vlad GALU
Sent: Monday, April 24, 2006 12:51 PM
To: freebsd-net@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
