On Tue, Jun 22, 2004 at 10:44:28PM -0400, Robert Huff wrote:
>       Poking around the system, I discovered the "m" option to
> netstat and got this:
> 261 mbufs in use
> 74/17088 mbuf clusters in use (current/max)
> 0/4/4528 sfbufs in use (current/peak/max)
> 213 KBytes allocated to network
> 0 requests for sfbufs denied
> 0 requests for sfbufs delayed
> 0 requests for I/O initiated by sendfile
> 935 calls to protocol drain routines
>       ... which would be a lot more useful if I had a reference
> standard.  Which I can't seen to find.

You're OK so long as the current and peak figures are less than the
max figure -- mbufs "memory buffers" are a fixed resource, out of
which sufficient space to handle network traffic has to be allocated.
If you have more traffic than the available space will cope with, then
you can't handle all incoming packets, and things will slow right
down.  On the other hand, if you allocate a lot more space for network
traffic, it is forever barred from being used for other purposes.

However, for most general purpose systems, just taking the autosized
defaults will give you plenty of space to handle incoming traffic
without being excessive.  You'ld really only have to look at modifying
the number of mbufs allocated for a very high traffic server.

>       This was taken on a system which has had minimal network
> traffic for several hours.  How would I expect things to change as
> load increased?  What are the warning signs the network is
> approaching saturation?

Keep an eye on the mbuf stats if you're worried.  So long as the in
use numbers don't climb above, say, 80% of the maximum even over a
traffic peak, you should be fine.  But I doubt you'll see anything
like that -- counters on my system show it uses about 2% of capacity.



Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

Attachment: pgpRlvCl9FyEA.pgp
Description: PGP signature

Reply via email to