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”, 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.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. |
Deze en andere documenten kunnen worden gedownload van ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Lees voor vragen over FreeBSD de documentatie alvorens contact te zoeken
<questions@FreeBSD.org>.
Vragen over deze documentatie kunnen per e-mail naar <doc@FreeBSD.org>.