🚀 go-pugleaf

In article <27BD8836.5548@orion.oac.uci.edu> iglesias@orion.oac.uci.edu (Mike Iglesias) writes:

   Can someone tell me what the "requests for clusters denied" means in
   netstat -m output?

There are two types of mbufs. One is a small character array which
tends to be used for character-oriented networking traffic and
networking data structures (sockaddrs and protocol control blocks)
inside the kernel. The other type of mbuf is the cluster. This points
at a page of kernel virtual memory and it tends to be used for bulk
networking traffic, typically file transfers.

If the system cannot allocate a cluster mbuf when one is required, it
increments a counter. It is the value of this counter that gets
displayed by netstat. Reasons for this vary. It may be that the mbuf
pool is empty. This should be rare - it should only happen when
there's a kernel bug that causes mbufs not to be freed when they are
no longer needed. [The mbuf pool can also be exhausted if there are
extremely high amounts of networking activity going on - i.e. many
thousands of active sockets in use.] If the mbuf pool is OK, a cluster
request can be denied because either the kernel cannot assign a page
table entry to it or allocate a page of physical memory to that page
table entry. Again, these should be rare events.

The most common reason will be that the mbuf pool is too small. In
short, there aren't enough mbufs to go round. This can be fixed by
reconfiguring the kernel to increase the size of the pool, just like
you'd increase the size of the file table or proc table if the system
was complaining that these tables were filled. The kernel cannot
complain about mbuf requests failing as the requests may be made at
interrupt time when it is not reasonable to print things on the system
console. 

		Jim

>/ iftccu:comp.sys.sequent / iglesias@orion.oac.uci.edu (Mike Iglesias) / 11:29 am  Feb 16, 1991 /
>Can someone tell me what the "requests for clusters denied" means in
>netstat -m output?  We've been having some strange network problems
>with our Sequent Symmetry running Dynix 3.0.12, and it seems to be
>related to that, in that the problems occur when that number has
>increased.  I've included a copy of the netstat -m output at the end
>of this message. 
>
>
>Thanks,
>
>Mike Iglesias
>University of California, Irvine
>Internet:    iglesias@orion.oac.uci.edu
>BITNET:      iglesias@uci
>uucp:        ...!ucbvax!ucivax!iglesias
>
>
>
>499/2272 mbufs in use:
>	73 mbufs allocated to data
>	33 mbufs allocated to packet headers
>	162 mbufs allocated to socket structures
>	84 mbufs allocated to socket peers
>	123 mbufs allocated to protocol control blocks
>	3 mbufs allocated to routing table entries
>	19 mbufs allocated to zombie process information
>	2 mbufs allocated to interface addresses
>29/200 mapped pages in use
>584 Kbytes allocated to network (18% in use)
>0 requests for memory denied
>4456 requests for clusters denied
>----------

Another post had a pretty good description of mbufs, but I have a couple of
things to add.  Mbufs are also used in regular old piping! (surprise :(.
This has the effect of making some commands like ls -l and so on not operate!
The netstat output above tells me that you took a hit in your networking at
some point.  I had a similar problem.  If it continues, it will eventually
crash your portmapper and the problem will disappear until you reboot.
If you have NFS running, but don't need it, you might try not starting the 
mountd daemon.  That solved a similar problem for me until the real 
problem was found.

I am on a large network (30000+ devices) and sometimes they don't all 
broadcast at the correct addresses.  This in usually doesn't mess us up
very badly, but there was this one HP that insisted on rebroadcasting
these packets MANY times quickly, which overloaded the networking 
capability of our machine.  This machine was finally found and shot 
through the ethernet board and our problem disappeared.  In this case,
increasing our mbufs probably wouldn't have solved the problem. 

This particular problem showed up only when we were running NFS.  

You appear to be running the default configuration for the number of mbufs,
but that is enough for us, running about 40-60 users.  You might want to 
contact sequent, I found them to be helpful in tracking this problem down.

Other things that I have found that can cause this problem are broadcasts
from things like routed and rusers and so on.  These all generate large 
quantities of responses and they are buffered in mbufs.  Good luck!
--------
Rick.