Re: Netzwerkpuffer Problem

On Wed, 2008-01-30 at 14:39 +0100, Bernd Walter wrote:
> 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.

Nein, das ist alles sauber. Mehrfach gecheckt.

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

Ok, das ist auf jedenfall einen Versuch wert, an mehr RAM soll es nicht
scheitern.

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

Das war eine Reaktion auf diese widersprüchlichen netstat Aussagen.
Die Werte waren als das Problem erkannt wurde auch noch default.

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

Das hätte ich gern probiert. Da der Server aber ein koreanisches Binary
ist würd ich vorher gerne den genauen Grund wissen, bevor ich
Programmierarbeiten dort eintüte. Dafür war auch die Vergrößerung des
maxsockbuf gedacht, da sich SO_SNDBUF laut setsockopt(2) auf höchstens
diese Größe aufblasen lässt.

Ich werd der Kiste mal 2G weiteren RAM spendieren und die KVA_PAGES wie
auch die kmem_size erhöhen.

Danke für die Antwort,
  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 - 15:28:43 CET