Re: Netzwerkpuffer Problem

On Wed, Jan 30, 2008 at 12:01:33PM +0100, Sascha Holzleiter wrote:
> 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.

Die erste Anlaufstelle bei Packetverlusten, die mit höherer DAtenrate
steigen sind die einstellungen der Netzwerkscnitstellen und zwar _aller_
also auf allen beteiligten Geräten, inklusive Switches.
Wenn die nicht jeweils paarweise korrekt eingestellt sind, bzw bei Repeaterhubs
überall auf Half-Duplex, dann gibt es solche Probleme.
Abver das ist scheinbar nicht dein Problem.

> 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.

Das ist natürlich was anderes.
Mag aber einen anderen Grund haben.
Die mbufs bedienen sich aus einem Speicherpool und wenn der keinen
physikalischen Speicher dazu bekommen kann, dann gibt es ähnliche
Effekte, aber das liegt nicht daran, dass der Pool selber erschöpft ist.

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

Ist Nietenzählen: es sind wohl genügend Puffer vorhanden, aber kein
Speicher dafür.
Du wirst vermutlich mehr kmem brauchen.

> 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

Das erklärt natürlich verdammt viel.
Bei 4000 Verbindungen brauchst du alleine zum Senden bereits bis zu 4G
kmem, was ein default-System niemals hergibt.
Und mit Empfangen theoretisch sogar bis zu 8G, wobei sich da seltener
viel ansammelt, da in der Regel nicht die Anwendung, sondern das Netzwerk
das NAdelöhr ist - muss jedoch nicht immer so sein.
Auf einem i386 kannst du das von Anfang an vergessen, weil der nicht mal
ausreichend Adressraum dafür hat und auf amd64 gibt es AFAIK eine
künstliche Grenze von 2G kmem, wegen 32bit signed an irgendeiner Stelle.
Hast du einen besonderen Grund die Werte derart hoch zu drehen?

> 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...

Es bleibt immer noch die Frage, warum du die Buffer so hoch drehst.
Die default liegen gerade mal bei 32k/64k.
Normalerweise dreht man das nur in speziellen Fällen hoch, nämlich wenn
man eine hohe Bandbreite auf einer Verbindungsstrecke mit hoher Latenz
ereichen will.
Der konkrete Bedarf lässt sich leicht errechnen, indem man die Laufzeit
mit der erforderten Bandbreite multipliziert und dann ein bischen Luft
addiert.
Bei 1MB und ~4000 Verbindungen möchte ich fast annehmen, dass du das
nicht wirklich brauchst und wenn doch, dann vermutlich nur mit wenigen
Verbindungen.
Die Werte sind nur defaults, d.h. jede Anwendung kann ihre Verbindungen
individuell mit größeren Buffern versehen, ohne dass gleich alle so
verschwenderisch mit den knappen Resourcen umgehen müssen.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd(at)bwct.de           info(at)bwct.de            support(at)fizon.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message