Netzwerkpuffer Problem

Moin,

ich hab hier auf einem Produktivrechner grad ein seltsames Problem, was
sich dahingehend auswirkt, dass man bei sehr vielen Verbindungen zu
einem Server (~4000) plötzlich 1-2% Paketverlust feststellen kann.
Was mich daran stutzig macht, sind die widersprüchlichen Aussagen der
Diagnosetools dazu.

Ein netstat -m gibt mir folgendes:

5421/2124/7545 mbufs in use (current/cache/total)
2988/1160/4148/25600 mbuf clusters in use (current/cache/total/max)
2988/200 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
7331K/2851K/10182K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
6725 calls to protocol drain routines

Was mir eigentlich sagt, das genügend mbufs vorhanden sind um das alles
zu bewältigen, ein netstat -s -p ip zeigt mir aber etwas anderes
(gekürzt):

        358817224 packets sent from this host
        0 packets sent with fabricated ip header
        704639712 output packets dropped due to no bufs, etc.

Es werden nicht gerade wenig Pakete einfach verworfen, weil wohl doch
nicht genügend Puffer zur Verfügung steht...

Die zuständigen sysctls hab ich eigentlich schon mit sehr großzügiger
Größe bedacht:

net.inet.tcp.sendspace: 1048576
net.inet.tcp.recvspace: 1048576
kern.ipc.somaxconn: 8192
kern.ipc.maxsockbuf: 16777216

Hätte hier evtl. noch jemand eine Idee wo das Nadelöhr sein könnte? Das
ganze ist ein 6.2 GENERIC mit ner em0 NIC auf 100Mbit von denen in der
Spitze gerademal 27Mbit ausgelastet sind...

MfG Sascha

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 30 Jan 2008 - 12:01:34 CET