Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Jan 2002 13:57:42 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Rogier R. Mulhuijzen" <drwilco@drwilco.net>
Cc:        TD790@aol.com, hackers@FreeBSD.ORG
Subject:   Re: Running out of bufferspace
Message-ID:  <3C3230D6.5CAC2135@mindspring.com>
References:  <5.1.0.14.0.20020101222654.01f413f0@mail.drwilco.net>

next in thread | previous in thread | raw e-mail | index | archive | help
"Rogier R. Mulhuijzen" wrote:
> At 11:42 1-1-2002 -0500, TD790@aol.com wrote:
> >Just note that  "no buffers" often means that the queue is full, not that you
> >are out of system buffers. You may be chasing a ghost.
> 
> Well a queue should be cleaned shouldn't it? The mount_smbfs fails even
> hours after I run the stresstest on my device.
> 
> And which queue exactly are we talking about, and where/how do I check its
> status?

Transmit queue depths are administratively limited.

Consider that the default is ~16k (there was some discussion
about upping this recently, which I think would be unwise).
So a server with would be limited to 125,000 connections, if
all transmit and receive queues were full, and there were a
total 4G of RAM dedicated to nothing other than buffers.

In practice, you can only sustain ~64k connections without
memory overcommit or window size adjustment of some kind
(overcommit works in this case, so long as you know what
you are ddoing, and understand queueing theory).

The problem you are running into is that your device is not
draining the transmit queue fast enough.

One way around this is to simply limk mbufs onto the transmit
queue (ignore the limits).  Another is the sysctl for send
space, which will let you up it to any number you want (but
you can run out of real memory and deadlock, if you set the
administrative limit so that it is effectively unlimited).

If you are hitting this limit, you should look at how your
device operates.  It would be a good idea to batch up your
requests, for example (e.g. like the interrupt coelescing
built into the Tigon II and Tigon III card drivers and
firmware, or like the soft interrupt coelescing patches I
posted for a number of network drivers a while back).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3230D6.5CAC2135>