AIX - Realmem, Thewall, Sb

orm@doc-tcpip.org

Erstellt: November 1999 - Letzte Modifikation: Juli 2001

Thewall, sb_max und Memory im Beispiel

Eine schlecht getunte Maschine

Auf einer eigenwillig getunten Maschine kann es aussehen wie hier gezeigt:
Die Maschine hat ein Gigabyte Real Memory (realmem 1048576). Der Adminstrator hat thewall getuned - womit bewiesen ist, das er nicht versteht wie es funktioniert: thewall = 131072. Man sollte immer den Standard-Wert nehmen - das ist entweder der Architektur-Bedingte Maximalwert oder die Hälfte des Speichers. Der Wert für die maximale Größe eines Sockets ist auf dieser Maschine sehr hoch: sb_max = 5242880 - satte 5 MB.
Die Send- und Receive-Spaces des TCP sind auf 0.25 MB eingestellt:
tcp_sendspace = 221184
tcp_recvspace = 221184
Das gilt pro Verbindung.

Was bedeutet das jetzt im einzelnen?

Diese Maschine ist bereit, von dem vorhandenen Gigabyte nur 128 MB für das Netzwerk zur Verfügung zu stellen - da muß dann alles hineinpassen: Jede Verbindung, Routing, DNS, Terminals etc. pp. Dann ist diese Maschine damit einverstanden, das ein Socket (also eine Telnet-Verbindung z.B.) insgesamt 5 MB Speicher beanspruchen darf. Mit den Einstellungen für den TCP Send- und Receive-Space erklärt diese Maschine, das sie bereit ist, 0.25 MB an Daten ohne Acknowledgement auf das Netz zu schicken und diese Menge auch im Speicher zu halten - bis eine Bestätigung eintrifft. Für den Receive-Space gilt dasselbe. Wenn man alles zusammenrechnet, dann stellt man fest, daß 256 Verbindungen nötig wären, um diese 128 MB Speicher aufzubrauchen (wobei natürlich pro Verbindung noch Routing-Daten usw. anfallen, die auch Speicher brauchen).

Wie wirkt sich soetwas aus?

Im Normalfall passiert eigentlich garnichts. Die Pakete, die Hereinkommen, werden abgearbeitet, es ist alles im Gleichgewicht, also die Puffer werden nie gefüllt. Dumm wird es nur, wenn das Netz so aussieht:

 
ETHERNET STATISTICS (ent1) :
Deferred: 1201096
1 collisions: 108231      6 collisions: 11         11 collisions: 0
2 collisions: 85373       7 collisions: 1          12 collisions: 0
3 collisions: 26668       8 collisions: 0          13 collisions: 0
4 collisions: 3841        9 collisions: 0          14 collisions: 0
5 collisions: 276        10 collisions: 0          15 collisions: 0

Es ist also ziemlich verstopft und zu. Es gehen sehr viele Pakete verloren und werden nochmals geschickt. Jetzt muß ein nicht bestätigtes Paket aber im Puffer gespeichert werden - die Puffer laufen also voll. Die Rechnung ist einfach: Wird auf zehn Verbindungen jeweils ein Paket verloren, so muß pro Verbindung ein TCP-Window an Daten gespeichert werden, also 0.25 MB. Das macht 2.2 MB, und das nur für den Sendspace. Allerdings wird der Verkehr in beide Richtungen Probleme haben; wenn die anderen Maschinen auch fleissig senden, entsprechend mehr Speicher wird gebraucht. Die Maschine erlaubt bis zu 5 MB, also im schlechtesten Fall wird pro Verbindung 5 MB Speicher gebunden. Es ist dann nur noch eine Frage der Zahl der Verbindungen und der Verstopfung auf dem Netz, um den Verkehr einzufrieren.

Was lernen wir daraus?

Sollte es wirklich nötig sein, so große Socket-Puffer zu haben (schwer vorzustellen) und sollte es nicht möglich sein, das Netzwerk zu beruhigen - Dann braucht man mehr Speicher für thewall. Wenn das die aktuelle Maschine nicht leistet, dann muß eine Größere her. Allerdings schiebt es das Problem nur auf. Denn sobald mehr Verbindungen eröffnet werden, ist man wieder am Ausgangspunkt.

Viel eher gibt es ein Problem mit dieser Implementation oder ein Mißverständnis der Grundlagen. Die Puffer sollten auf die Standard-Werte herabgesetzt werden und die Anzahl der gleichzeitigen Verbindungen müssen gegen den Verbrauch der Puffer abgewogen werden. Das bezieht sich besonders auf die Gegenstellen, den wenn der Send-space vollläuft, dann bedeutet das, daß die Gegenseite nicht nachkommt mit dem Abarbeiten und Bestätigen. Die Maschine sendet dann blind, muß alles speichern und bekommt dann noch eine Reihe von Retransmissions aufs Auge.
Speziell Windows-PCs sind hier ein Spass, da sie mit sehr kleinen Puffern (8K) ausgeliefert werden, also ein Sendspace von 0.25 MB völlig überdimensioniert ist.

[ Main | Local ]

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