kern.maxfiles
kern.maxfiles
kan worden verhoogd of verlaagd,
afhankelijk van de systeembehoeften. Deze variabele geeft het maximale aantal
bestandsdescriptors op een systeem. Als de bestandsdescriptortabel vol is, toont de
systeembuffer meerdere malen file: table is full, het geen
achteraf te zien is met dmesg.
Elk geopend bestand, socket of fifo heeft een bestandsdescriptor. Een grote produktieserver kan makkelijk enige duizenden bestandsdescriptors nodig hebben, afhankelijk van het soort en aantal diensten die tegelijk draaien.
In oudere versies van FreeBSD werd de standaard waarde van kern.maxfiles
afgeleid van de optie maxusers
in het kernelconfiguratiebestand. kern.maxfiles
groeit
evenredig met de waarde van maxusers. Als een aangepaste kernel
wordt gebouwd, is het een goed idee om deze kerneloptie in te stellen afhankelijk van het
gebruikt van een systeem (maar niet te laag). Hoewel een produktieserver misschien niet
256 gelijktijdige gebruikers heeft, kunnen de benodigde systeembronnen het beste
vergeleken worden met een grootschalige webserver.
De optie maxusers stelt de grootte van een aantal belangrijke systeemtabellen in. Dit aantal moet ruwweg gelijk zijn aan het aantal gebruikers dat verwacht wordt gelijktijdig van de machine gebruik te maken.
Vanaf FreeBSD 4.5 wordt kern.maxusers
automatisch
ingesteld tijdens het opstarten gebaseerd op de hoeveelheid beschikbare geheugen in het
systeem en kan worden vastgesteld tijdens het draaien door te kijken naar de alleen-lezen
sysctl kern.maxusers
. Sommige configuraties hebben grotere
of kleinere waarden nodig van kern.maxusers
, deze kunnen
worden gezet als een opstartvariabele. Waardes van 64, 128 en 256 zijn daarin niet
ongewoon. We raden aan om niet boven de 256 te gaan tenzij er heel veel
bestandsdescriptors benodigd zijn; veel van de aanpasbaare waarden die standaard worden
bepaald door kern.maxusers
kunnen individueel worden
overschreven tijdens het opstarten en/of tijdens het draaien van het systeem in
/boot/loader.conf (zie de handleiding loader.conf(5) of het
bestand /boot/defaults/loader.conf voor een paar aanwijzingen)
of zoals elders beschreven in dit document. Systemen die ouder zijn dan FreeBSD 4.4
moeten deze waarden instellen via de kerneloptie config(8) maxusers
.
Voor oudere versies stelt het systeem deze waarde zelf in als deze uitdrukkelijk op 0 is gezet. [1]
Als het gewenst is om deze waarde zelf aan te geven, wordt aangeraden om maxusers minstens op 4 te zetten, met name als het X Window systeem in gebruik is of als er software gecompileerd wordt. De reden hiervoor is dat de belangrijkste tabel die door maxusers ingesteld wordt, het maximum aantal processen is, dat ingesteld wordt op 20 + 16 * maxusers, dus als maxusers op 1 ingesteld wordt, zijn er maar 36 gelijktijdige processen mogelijk, inclusief de ongeveer achttien processen die door het systeem tijdens het opstarten start en de ongeveer vijftien processen die waarschijnlijk aangemaakt worden door het opstarten van het X Window systeem. Zelfs een eenvoudige taak als het afbeelden van een hulppagina start negen processen op om de pagina te filteren, te decomprimeren en af te beelden. Als maxusers op 64 ingesteld wordt, zijn er 1044 gelijktijdige processen mogelijk, wat genoeg moet zijn voor bijna alle soorten gebruik. Als echter de gevreesde fout proc table full verschijnt als er geprobeerd wordt om een programma op te starten of als er een server gedraaid wordt met een groot aantal gelijktijdige gebruikers, zoals ftp.FreeBSD.org, kan het getal altijd verhoogd worden en kan de kernel opnieuw gebouwd worden.
Opmerking: maxusers stelt geen grens aan het aantal gebruikers dat zich op de machine kan aanmelden. Het stelt gewoon verschillende tabelgroottes in op redelijke waardes, uitgaande van het maximum aantal gebruikers dat waarschijnlijk de machine gebruikt en van het aantal processen dat elk van deze gebruikers zal draaien. Een sleutelwoord dat wel het aantal gelijktijdige aanmeldingen op afstand en X-terminalvensters begrensd is pseudo-device pty 16. In FreeBSD 5.X kan dit getal genegeerd worden omdat daar het stuurprogramma pty(4) auto-cloning is. Er kan eenvoudig gebruik worden gemaakt van de regel device pty in het instellingenbestand.
kern.ipc.somaxconn
De sysctl-variabele kern.ipc.somaxconn
beparkt de grootte
van de luisterwachtrij voor het accepteren van nieuwe TCP-verbindingen. De
standaardwaarde van 128 is meestal te laag voor robuuste
behandeling van nieuwe verbindingen in een zwaarbeladen webserveromgeving. Voor zulke
omgevingen wordt aangeraden deze waarde te verhogen tot 1024 of
hoger. De dienstdaemon beperkt misschien zelf de luisterwachtrij (bijvoorbeeld sendmail(8) of Apache), maar heeft vaak een mogelijkheid in een configuratiebestand de
wachtrijgrootte aan te passen. Grote luisterwachtrijen zijn ook beter in het ontwijken
van Ontzegging van Dienst (DoS) aanvallen.
De kerneloptie NMBCLUSTERS bepaalt het aantal netwerk-Mbufs
dat beschikbaar is voor een systeem. Een veel bezochte server met een laag aantal Mbufs
beperkt de mogelijkheden van FreeBSD. Elk cluster staat voor ongeveer 2 K geheugen, dus
een waarde van 1024 stelt 2 megabyte aan kernelgeheugen voor, dat is gereserveerd voor
netwerkbuffers. Een simpele berekening geeft aan hoeveel er nodig is. Stel dat een
webserver met een maximum van 1000 simultane verbindingen voor elke verbinding 16 K aan
ontvangstnetwerkbuffers en 16 K aan zendbuffers kost, dan is ongeveer 32 MB aan
netbuffers nodig voor de webserver. Een goede vuistregel is te vermeniguldigen met twee,
dus 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Voor machines met veel geheugen wordt 4096 tot
32768 aangeraden. Er moet in geen geval een arbitrair hoge waarde voor deze sysctl
opgegeven worden, want dat kan leiden tot een crash tijdens het opstarten. Met de optie
-m
van netstat(1) kan het
clustergebruik van het netwerk bekeken worden.
De loaderparameter kern.ipc.nmbclusters
moet gebruikt
worden om dit tijdens het opstarten toe te passen. Alleen voor oudere versies van FreeBSD
is het nodig om de kerneloptie NMBCLUSTERS te gebruiken.
Voor drukke servers die extensief gebruik maken van de systeemaanroep sendfile(2), kan het nodig
zijn het aantal sendfile(2)-buffers te
verhogen via de kerneloptie NSFBUFS of door de waarde in te
stellen in /boot/loader.conf (in loader(8) staan details).
Als er in de procestabel processen staan met een status sfbufa
is dat een algemene indicator dat deze parameter aangepast moet worden. De
sysctl-variabele kern.ipc.nsfbufs
is alleen-lezen en laat
zien op welke waarde deze kernelvariabele is ingesteld. Deze parameter schaalt engiszins
met de variabele kern.maxusers
, maar het kan nodig zijn om
deze bij te stellen.
Belangrijk: Zelfs als een socket als non-blocking gemarkeerd is, dan nog kan het aanroepen van sendfile(2) op de non-blocking socket ertoe leiden dat er toch blokkade optreedt totdat er voldoende struct sf_buf's vrijgemaakt zijn.
net.inet.ip.portrange.*
De sysctl-variabelen net.inet.ip.portrange.*
bepalen
welke reeks poortnummers automatisch gebonden wordt aan TCP- en UDP-sockets. Er zijn drie
gebieden: een laag gebied, een (standaard) middengebied en een hoog gebied. De meeste
netwerkprogramma's gebruiken het standaardbereik, wat begrensd wordt door net.inet.ip.portrange.first
en net.inet.ip.portrange.last
met standaardwaarden van respectievelijk 1024
en 5000. Gebonden poortreeksen worden gebruikt voor uitgaande verbindingen en het is
onder bepaalde omstandigheden mogelijk dat poorten op raken. Dit gebeurt meestal in het
geval van een zwaar belaste webproxy. Poortbereik is niet van belang als vooral diensten
draaien die zich bezighouden met inkomende verbindingen, zoals een normale webserver, of
als het aantal uitgaande verbindingen beperkt is, zoals bij een mailrelay. Voor situaties
waarin een tekort aan poorten dreigt, wordt aangeraden om net.inet.ip.portrange.last
bescheiden op te hogen. Een waarde van
10000, 20000 of 30000 is redelijk. Er moet ook rekening met effecten op firewalls gehouden
worden als de poortreeks gewijzigd wordt. Sommige firewalls kunnen grote poortreeksen
blokkeren, meestal de lagere poorten, en verwachten dat andere systemen hogere poorten
gebruiken voor uitgaande verbindingen. Om deze reden wordt het niet aanbevolen om
net.inet.ip.portrange.first
te verlagen.
De TCP-bandbreedtevertragingsproductlimitatie lijkt op TCP/Vegas in NetBSD. Het kan
aangezet worden door de sysctl-variabele net.inet.tcp.inflight.enable
de waarde 1 te
geven. Het systeem tracht dan het bandbreedtevertragingssprodukt te berekenen voor elke
verbinding en beperkt dan de hoeveelheid gegevens in de wachtrij naar het netwerk tot de
hoeveelheid die vereist is om maximale doorvoer te kunnen handhaven.
Dit is nuttig bij gebruik van modems, Gigabit Ethernet of zelfs bij WAN-verbindingen
met hoge snelheid (of elke andere verbinding met een groot
bandbreedtevertragingsprodukt), in het bijzonder als ook windowschaling of een groot
verzendwindow gebruikt wordt. Als deze optie aangezet wordt, dient ook net.inet.tcp.inflight.debug
de waarde 0 te
krijgen (geen debugging) en voor produktiegebruik kan het instellen van net.inet.tcp.inflight.min
naar minstens 6144
voordeel opleveren. Het instellen van hoge minima kan effectief het beperken van
bandbreedte ondermijnen, afhankelijk van de verbinding. De mogelijkheid tot limitering
zorgt ervoor dat de hoeveelheid gegevens die opgebouwd wordt, in tussentijdse route- en
switchwachtrijen verlaagd kan worden en tevens kan de hoeveelheid gegevens die opgebouwd
wordt in de interfacewachtrij van de lokale host verlaagd worden. Met minder pakketten in
wachtrijen kunnen interactieve verbindingen opereren met lagere Round Trip tijden, met name over langzame
modems. Deze optie gaat alleen over datatransmissie (upload / serverkant) en heeft geen
effect gegevensontvangst (download / cliëntkant).
Aanpassen van net.inet.tcp.inflight.stab
wordt
niet aangeraden. Deze parameter
krijgt standaard een waarde van 20, wat 2 maximale pakketten opgeteld bij de
bandbreedtevensterberekening representeert. Het extra venster is nodig om het algoritme
stabiel te houden en om de reactietijd bij veranderende omstandigheden te verbeteren,
maar het kan ook leiden tot langere pingtijden over langzame verbindingen (zonder het
inflight-algoritme kan dit echter nog erger zijn). In dergelijke gevallen kan deze
parameter misschien verlaagd worden naar 15, 10 of 5 en misschien moet voor het gewenste
effect ook net.inet.tcp.inflight.min
verlaagd worden
(bijvoorbeeld naar 3500). Het verlagen van deze parameters moet pas in laatste instantie
overwogen worden.
kern.maxvnodes
Een vnode is de interne representatie van een bestand of een map. Het verlagen van het aantal beschikbare vnodes voor het besturingssysteem leidt dus tot een daling van schijf-I/O. Normaliter wordt dit door het besturingssysteem afgehandeld en hoeft de instelling niet gewijzigd te worden. Im sommige gevallen kan schijf-I/O de beperkende factor zijn en kan het systeem alle beschikbare vnodes in gebruik hebben. Dan dient deze instelling gewijzigd te worden. De hoeveelheid inactief en beschikbaar RAM dient meegenomen te worden in de beslissing.
Het huidige aantal gebruikte vnodes kan als volgt bekeken worden:
# sysctl vfs.numvnodes vfs.numvnodes: 91349
Om het maximale aantal vnodes weer te geven:
# sysctl kern.maxvnodes kern.maxvnodes: 100000
Als het huidige aantal gebruikte vnodes dicht bij het maximale aantal ligt, is het
verstandig om kern.maxvnodes
op te hogen met 1.000. Ook
vfs.numvnodes
dient in de gaten gehouden te worden. Als de
waarde weer tot aan het maximum stijgt, dan moet kern.maxvnodes
verder opgehoogd worden. Er dient een verschuiving op te
treden in het door top(1) gerapporteerde
geheugengebruik. Er hoort meer geheugen actief te zijn.
[1] |
Het auto-tuning-algoritme stelt maxusers in afhankelijk van de hoeveelheid geheugen in het systeem, met een minimum van 32 en een maximum van 384. |