Abhängig von den Anforderungen an das System kann die
sysctl(8)-Variable kern.maxfiles
erhöht oder gesenkt werden. Die Variable legt die maximale
Anzahl von Dateideskriptoren auf dem System fest. Wenn die
Dateideskriptoren aufgebraucht sind, werden Sie die Meldung
file: table is full wiederholt im
Puffer für Systemmeldungen sehen. Den Inhalt des Puffers
können Sie sich mit dmesg(8) anzeigen lassen.
Jede offene Datei, jedes Socket und jede FIFO verbraucht einen Dateideskriptor. Auf „dicken“ Produktionsservern können leicht Tausende Dateideskriptoren benötigt werden, abhängig von der Art und Anzahl der gleichzeitig laufenden Dienste.
In älteren FreeBSD-Versionen wurde die Voreinstellung
von kern.maxfile
aus der
Kernelkonfigurationsoption maxusers
bestimmt. kern.maxfiles
wächst
proportional mit dem Wert von maxusers
.
Wenn Sie einen angepassten Kernel kompilieren, empfiehlt es
sich diese Option entsprechend der maximalen Benutzerzahl
des Systems einzustellen. Obwohl auf einer
Produktionsmaschine vielleicht nicht 256 Benutzer
gleichzeitig angemeldet sind, können die benötigten
Ressourcen ähnlich hoch wie bei einem großen Webserver
sein.
Die nur lesbare sysctl(8)-Variable
kern.maxusers
wird beim Systemstart
automatisch aus dem zur Verfügung stehenden Hauptspeicher
bestimmt. Im laufenden Betrieb kann dieser Wert aus
kern.maxusers
ermittelt werden. Einige
Systeme benötigen für diese Variable einen anderen Wert,
wobei 64
, 128
und
256
gewöhnliche Werte darstellen.
Es wird nicht empfohlen, die Anzahl der Dateideskriptoren
auf einen Wert größer 256
zu setzen, es
sei denn, Sie benötigen wirklich eine riesige Anzahl von
ihnen. Viele der von kern.maxusers
auf
einen Standardwert gesetzten Parameter können beim
Systemstart oder im laufenden Betrieb in
/boot/loader.conf
angepasst werden.
In loader.conf(5) und
/boot/defaults/loader.conf
finden Sie
weitere Details und Hinweise.
Ältere FreeBSD-Versionen setzen diesen Wert selbst, wenn
Sie in der Konfigurationsdatei den Wert 0
[2]
angeben. Wenn Sie den Wert selbst bestimmen wollen,
sollten Sie maxusers
mindestens auf
4
setzen. Dies gilt insbesondere dann,
wenn Sie beabsichtigen, Xorg zu
benutzen oder Software zu kompilieren. Der wichtigste Wert,
der durch maxusers
bestimmt wird, die
maximale Anzahl an Prozessen ist, die auf
20 + 16 * maxusers
gesetzt wird. Wird
maxusers
auf 1
setzen,
können gleichzeitig nur 36
Prozesse
laufen, von denen ungefähr 18
schon beim
Booten des Systems gestartet werden. Dazu kommen nochmals
etwa 15
Prozesse beim Start von
Xorg. Selbst eine einfache
Aufgabe wie das Lesen einer Manualpage benötigt neun
Prozesse zum Filtern, Dekomprimieren und Betrachten der
Datei. Für die meisten Benutzer sollte es ausreichen,
maxusers
auf 64
zu
setzen, womit 1044
gleichzeitige Prozesse
zur Verfügung stehen. Wenn Sie allerdings den Fehler
proc table full beim Start eines
Programms oder auf einem Server mit einer großen
Benutzerzahl sehen, dann sollten Sie den Wert nochmals
erhöhen und den Kernel neu bauen.
Die Anzahl der Benutzer, die sich auf einem
Rechner anmelden kann, wird durch
maxusers
nicht
begrenzt. Der Wert dieser Variablen legt neben der
möglichen Anzahl der Prozesse eines Benutzers weitere
sinnvolle Größen für bestimmte Systemtabellen fest.
Die sysctl(8)-Variable
kern.ipc.soacceptqueue
beschränkt die
Größe der Warteschlange
(Listen-Queue) für neue
TCP-Verbindungen. Der Vorgabewert von
128
ist normalerweise zu klein, um neue
Verbindungen auf einem stark ausgelasteten Webserver
zuverlässig zu handhaben. Auf solchen Servern sollte
der Wert auf 1024
oder höher gesetzt
werden. Dienste wie sendmail(8) oder
Apache können die Größe
der Queue selbst einschränken. Oft gibt es die
Möglichkeit, die Größe der Listen-Queue in
einer Konfigurationsdatei einzustellen. Eine große
Listen-Queue übersteht vielleicht auch einen
Denial of Service Angriff (DoS).
Die Kerneloption NMBCLUSTERS
schreibt
die Anzahl der Netzwerkpuffer (Mbufs) fest, die das System
besitzt. Eine zu geringe Anzahl Mbufs auf einem Server mit
viel Netzwerkverkehr verringert die Leistung von FreeBSD. Jeder
Mbuf-Cluster nimmt ungefähr 2 kB Speicher in Anspruch, so
dass ein Wert von 1024
insgesamt
2 Megabyte Speicher für Netzwerkpuffer im System
reserviert. Wie viele Cluster benötigt werden, lässt sich
durch eine einfache Berechnung herausfinden. Ein Webserver,
der maximal 1000
gleichzeitige Verbindungen
servieren soll, wobei jede der Verbindungen einen 6 kB
großen Sendepuffer und einen 16 kB großen Empfangspuffer
benötigt, braucht ungefähr 32 MB Speicher für
Netzwerkpuffer. Als Daumenregel verdoppeln Sie diese Zahl, so
dass sich für NMBCLUSTERS
der Wert
2x32 MB / 2 kB=
64 MB / 2 kB=
32768
ergibt. Für Maschinen mit viel
Speicher werden Werte zwischen 4096
und
32768
empfohlen. Unter keinen Umständen
sollten Sie diesen Wert willkürlich erhöhen, da dies zu einem
Absturz beim Systemstart führen kann. Verwenden Sie
netstat(1) mit -m
um den Gebrauch der
Netzwerkpuffer zu kontrollieren.
Die Netzwerkpuffer können beim Systemstart mit der
Loader-Variablen kern.ipc.nmbclusters
eingestellt werden. Nur auf älteren FreeBSD-Systemen
müssen Sie die Kerneloption NMBCLUSTERS
verwenden.
Die Anzahl der sendfile(2) Puffer muss auf
ausgelasteten Servern, die den Systemaufruf sendfile(2)
oft verwenden, vielleicht erhöht werden. Dazu können Sie die
Kerneloption NSFBUFS
verwenden oder die
Anzahl der Puffer in /boot/loader.conf
(siehe loader(8)) setzen. Die Puffer sollten erhöht
werden, wenn Sie Prozesse im Zustand sfbufa
sehen. Die schreibgeschützte sysctl(8)-Variable
kern.ipc.nsfbufs
zeigt die Anzahl
eingerichteten Puffer im Kernel. Der Wert dieser Variablen
wird normalerweise von kern.maxusers
bestimmt. Manchmal muss die Pufferanzahl jedoch manuell
eingestellt werden.
Auch wenn ein Socket nicht blockierend angelegt wurde,
kann der Aufruf von sendfile(2) blockieren, um auf
freie struct sf_buf
Puffer zu
warten.
Die sysctl(8)-Variable
net.inet.ip.portrange.*
legt die
Portnummern für TCP- und
UDP-Sockets fest. Es gibt drei
Bereiche: den niedrigen Bereich, den normalen Bereich und
den hohen Bereich. Die meisten Netzprogramme benutzen den
normalen Bereich. Dieser Bereich umfasst in der
Voreinstellung die Portnummern 1024
bis
5000
und wird durch die Variablen
net.inet.ip.portrange.first
und
net.inet.ip.portrange.last
festgelegt. Die festgelegten Bereiche für Portnummern
werden von ausgehenden Verbindungen benutzt. Unter
bestimmten Umständen, beispielsweise auf stark ausgelasteten
Proxy-Servern, sind alle Portnummern für ausgehende
Verbindungen belegt. Bereiche
für Portnummern spielen auf Servern keine Rolle, die
hauptsächlich eingehende Verbindungen verarbeiten (wie ein
normaler Webserver) oder nur eine begrenzte Anzahl
ausgehender Verbindungen öffnen (beispielsweise ein
Mail-Relay). Wenn keine freien Portnummern mehr vorhanden
sind, sollte die Variable
net.inet.ip.portrange.last
langsam
erhöht werden. Ein Wert von 10000
,
20000
oder 30000
ist
angemessen. Beachten Sie auch eine vorhandene Firewall,
wenn Sie die Bereiche für Portnummern ändern. Einige
Firewalls sperren große Bereiche (normalerweise aus den
kleinen Portnummern) und erwarten, dass hohe Portnummern für
ausgehende Verbindungen verwendet werden. Daher kann es
erforderlich sein, den Wert von
net.inet.ip.portrange.first
zu
erhöhen.
Die TCP
Bandwidth Delay Product
Begrenzung wird aktiviert, indem die sysctl(8)-Variable
net.inet.tcp.inflight.enable
auf den
Wert 1
gesetzt wird. Das System wird
dadurch angewiesen, für jede Verbindung, das Produkt aus der
Übertragungsrate und der Verzögerungszeit zu bestimmen.
Dieses Produkt begrenzt die Datenmenge, die für einen
optimalen Durchsatz zwischengespeichert werden muss.
Diese Begrenzung ist nützlich, wenn Sie Daten
über Verbindungen mit einem hohen Produkt aus
Übertragungsrate und Verzögerungszeit wie Modems,
Gigabit-Ethernet oder schnellen WANs, zur
Verfügung stellen. Insbesondere wirkt sich die Begrenzung
aus, wenn die Verbindung die Option
Window-scaling verwendet oder
große Sende-Fenster
(send window) benutzt.
Schalten Sie die Debug-Meldungen aus, wenn Sie die
Begrenzung aktiviert haben. Dazu setzen Sie die Variable
net.inet.tcp.inflight.debug
auf
0
. Auf Produktions-Systemen sollten Sie
zudem die Variable
net.inet.tcp.inflight.min
mindestens auf
den Wert 6144
setzen. Allerdings kann
ein zu hoher Wert, abhängig von der Verbindung, die
Begrenzungsfunktion unwirksam machen. Die Begrenzung
reduziert die Datenmenge in den Queues von Routern und
Switches, sowie die Datenmenge in der Queue der lokalen
Netzwerkkarte. Die Verzögerungszeit
(Round Trip Time) für
interaktive Anwendungen sinkt, da weniger Pakete
zwischengespeichert werden. Dies gilt besonders für
Verbindungen über langsame Modems. Die Begrenzung
wirkt sich allerdings nur auf das Versenden von Daten aus
(Uploads, Server). Auf den Empfang von Daten (Downloads)
hat die Begrenzung keine Auswirkungen.
Die Variable
net.inet.tcp.inflight.stab
sollte
nicht angepasst werden. Der
Vorgabewert der Variablen beträgt 20
,
das heißt es werden maximal zwei Pakete zu dem Produkt
aus Übertragungsrate und Verzögerungszeit addiert.
Dies stabilisiert den Algorithmus und verbessert die
Reaktionszeit auf Veränderungen. Bei langsamen
Verbindungen können sich aber die Laufzeiten der Pakete
erhöhen (ohne diesen Algorithmus wären sie allerdings noch
höher). In solchen Fällen können Sie versuchen, den Wert
der Variablen auf 15
,
10
oder 5
herabzusetzen. Gleichzeitig müssen Sie vielleicht auch
net.inet.tcp.inflight.min
auf einen
kleineren Wert (beispielsweise 3500
)
setzen. Ändern Sie diese Variablen nur ab, wenn Sie
keine anderen Möglichkeiten mehr haben.
Ein vnode ist die interne Darstellung einer Datei oder eines Verzeichnisses. Die Erhöhung der Anzahl der für das Betriebssystem verfügbaren vnodes verringert also die Schreib- und Lesezugriffe auf der Festplatte. vnodes werden im Normalfall vom Betriebssystem automatisch vergeben und müssen nicht manuell angepasst werden. In einigen Fällen stellt der Zugriff auf eine Platte allerdings einen Flaschenhals dar, daher sollten Sie in diesem Fall die Anzahl der möglichen vnodes erhöhen, um dieses Problem zu beheben. Beachten Sie dabei aber die Größe des inaktiven und freien Hauptspeichers.
Um die Anzahl der derzeit verwendeten vnodes zu sehen, geben Sie Folgendes ein:
#
sysctl vfs.numvnodes
vfs.numvnodes: 91349
Die maximal mögliche Anzahl der vnodes erhalten Sie durch die Eingabe von:
#
sysctl kern.maxvnodes
kern.maxvnodes: 100000
Wenn sich die Anzahl der genutzten vnodes dem maximal
möglichen Wert nähert, sollten Sie den Wert
kern.maxvnodes
zuerst um etwa
1000
erhöhen. Beobachten Sie danach die
Anzahl der vom System genutzten
vfs.numvnodes
. Nähert sich der Wert
wiederum dem definierten Maximum, müssen Sie
kern.maxvnodes
nochmals erhöhen. Sie
sollten nun eine Änderung des Speicherverbrauches über
top(1) registrieren können und über mehr aktiven
Speicher verfügen.
[2] Der verwendete Algorithmus setzt
maxusers
auf die Speichergröße des
Systems. Der minimale Wert beträgt dabei
32
, das Maximum ist
384
.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.