[ Main | Local ]

Ein Experiment mit Netzwerk-Puffern

Für dieses lehrreiche Experiment braucht man zwei AIX-Maschinen und eine grafische Oberfläche (CDE) mit drei Fenstern. Natürlich ist es keine gute Idee, das Ganze auf einer Produktionsmaschine durchzuführen - das Netzwerk wird für diese Maschine während der Aktion nicht nutzbar sein.

Im ersten Fenster läßt man mit diesem Skript das Kommando netstat -m in einer Schleife laufen:

  
while [ 1 ] ; do
netstat -m | grep -p mbuf
sleep 1
clear
done
 

 
while [ 1 ] ; do
netstat -an | grep 23
sleep 1
clear
done
 

Im dritten Fenster setzt man TCP Send- und Receive-Space auf ordentlich hohe Werte, z.B. so: no -o tcp_sendspace=512000
no -o tcp_recvspace=512000
Man muß jetzt den inetd neu starten, damit alle offenen (lauschenden, LISTEN) Sockets die Änderung mitbekommen:
stopsrc -s inetd ; startsrc -s inetd

Will man die Sache knackiger durchziehen, so kann man bei dieser Gelegenheit thewall noch auf einige MB herunterschrauben.

Jetzt loggt man sich auf der so vorbereiteten Maschine von einer anderen ein. Da eine TCP-Session nicht allzu viel Last erzeugt, wiederholt man das Login zyklisch ineinander geschachtelt. Also zuerst ein normaler Login, dann wiederholter Login auf sich selbst (40 - 60 mal):
tn 0

Wir haben jetzt eine Kette von Telnet-Sessions, deren Sockets logischerweise auch miteinander verkettet sind. Das sieht man in der Ausgabe des netstat -a. Schaut man sich jetzt nochmal den netstat -m an (mbufs inuse), dann sieht man, das sich noch nichts getan hat. Das soll sich jetzt ändern:
Im letzten Fenster der verketteten Telnet-Sessions wird eine Datenübertragung angestoßen - ein Telnet auf den Port 19 (Zeichengenerator, chargen) der eigenen Maschine:
tn 0 19
Damit verliert man die Kontrolle über dieses Terminal, aber egal. Interessant ist, was der netstat sagt; jetzt ist etwas Last auf dem Stack, und die Werte ändern sich ein wenig.

Um das ganze zum Zusammenbruch zu bringen geht man zurück auf die erste Maschine - also dort, wo die Telnet-Verbindung endet - und friert dort diese Telnet Session ein (indem man den dbx an die entsprechende PID hängt).

Was jetzt passiert: der "mbufs in use"-Wert fliegt jetzt in ungeahnte Höhen - und das in Sekunden. Hat man den Wert für thewall genügend herabgesetzt, so bekommt man einige mbufs denied. In der Ausgabe des netstat -a sieht man, das sich die Receive-Queue/Send-Queues mit den Paketen füllen - und zwar genau auf die 512000 Byte, die man oben eingestellt hat. Das ist, was jetzt den ganzen Speicher für das Netzwerk auffrißt.
Das ist der richtige Moment, um die Telnet Session wieder freizugeben und diese Session mit dem kill-Kommando aus der Welt zu schaffen. Im netstat sieht man dann, das die benutzten Puffer innerhalb von Sekunden auf ihren Ausgangswert zurückfallen. Und die gefüllten Warteschlangen sind auch sofort wieder leer.

Eine Sache bezüglich des netstat-Kommandos ist eine technische: Das Kommando blockiert das Kernel-Memory (/dev/kmem) nicht (wäre ja auch Unsinn). Die mbufs sind aber als verkettete Listen angelegt, die wegen der Natur der Dinge stark flüchtig sind. Das bedeutet, daß die Angaben des netstat nicht genau sind und nur Spitzenlasten in einem bestimmten Moment wiedergeben. Netstat Ausgaben sind also ein Indiz, aber keine harten Nummern.

Vielen Dank an Robert Manning vom IBM Support in Austin (L3TCP) für dieses Experiment.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]