kern.maxfileskern.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”, hetgeen 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
/boot/defaults/loader.conf voor een paar
aanwijzingen) of zoals elders beschreven in dit document.
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.somaxconnDe 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.maxvnodesEen 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. |