Le paramètre kern.maxfiles
peut être augmenté ou diminué
en fonction des besoins du système. Cette variable
indique le nombre maximal de descripteurs de fichier sur
votre système. Quand la table de descripteurs de fichier
est pleine, le message file: table is
full s'affichera régulièrement dans le
tampon des messages système, qui peut être
visualisé avec la commande
dmesg
.
Chaque fichier ouvert, chaque “socket”, ou chaque emplacement en pile utilise un descripteur de fichier. Un serveur important peut facilement demander plusieurs milliers de descripteurs de fichiers, en fonction du type et du nombre de services s'exécutant en même temps.
Sous les anciennes versions de FreeBSD, la valeur par défaut de kern.maxfile
est fixée par l'option maxusers
dans votre fichier de configuration du noyau.
kern.maxfiles
augmente proportionnellement
avec la valeur de maxusers
. Quand vous
compilez un noyau sur mesure, il est bon de paramétrer cette
option en fonction de l'utilisation de votre système. Ce
nombre fixe la plupart des limites pré-définies du
noyau.
Même si une machine de production pourra ne pas avoir en
réalité 256 utilisateurs connectés
simultanément, les ressources requises pourront être
semblables pour un serveur web important.
Depuis FreeBSD 4.5, kern.maxusers
est
automatiquement ajustée au démarrage en
fonction de la quantité de mémoire disponible
dans le système, sa valeur peut être connue
durant le fonctionnement du système en examinant la
valeur de la variable sysctl en lecture seule:
kern.maxusers
. Certains systèmes
auront besoin de valeurs plus élevées ou plus
faibles pour kern.maxusers
et pourront
donc la fixer au chargement du système; des valeurs
de 64, 128, ou 256 ne sont pas inhabituelles. Nous
recommandons de ne pas dépasser 256 à moins
que vous ayez besoin d'un grand nombre de descripteurs de
fichiers; plusieurs des variables dont la valeur par
défaut dépend de
kern.maxusers
peuvent être
fixées individuellement au démarrage ou en
fonctionnement dans le fichier
/boot/loader.conf
(voir la page de
manuel loader.conf(5) ou le fichier
/boot/defaults/loader.conf
pour des
exemples) ou comme décrit en d'autres endroits dans
ce document. Les systèmes antérieurs à
FreeBSD 4.4 doivent passer par l'option
maxusers
du fichier de configuration du
noyau pour fixer cette valeur.
Sous les anciennes versions, le système auto-ajuste
ce paramètre pour vous si vous le fixez explicitement
à 0
[5].
En paramétrant cette option, vous
devrez fixer maxusers
à 4 au
moins, en particulier si vous utilisez le système X
Window ou compilez des logiciels. La raison de cela est que
la valeur la plus importante que dimensionne
maxusers
est le nombre maximal de
processus, qui est fixé à 20 + 16 *
maxusers
, donc si vous positionnez
maxusers
à 1, alors vous ne pouvez
avoir que 36 processus en simultanés, comprenant les
18, environ, que le système lance au démarrage
et les 15, à peu près, que vous créerez
probablement au démarrage du système X Window.
Même une tâche simple comme la lecture d'une
page de manuel lancera jusqu'à neuf processus pour la
filtrer, la décompresser, et l'afficher. Fixer
maxusers
à 64 autorisera
jusqu'à 1044 processus simultanés, ce qui
devrait suffire dans la plupart des cas. Si, toutefois,
vous obtenez le message d'erreur tant redouté
proc table full quand vous tentez
d'exécuter un nouveau programme, ou gérez un
serveur avec un grand nombre d'utilisateurs en
simultanés (comme ftp.FreeBSD.org
), vous pouvez toujours
augmenter cette valeur et recompiler le noyau.
maxusers
ne limite
pas le nombre d'utilisateurs qui
pourront ouvrir une session sur votre machine. Cette
valeur dimensionne simplement différentes tables
à des valeurs raisonnables en fonction du nombre
maximal d'utilisateur que vous aurez vraisemblablement sur
votre système et combien de processus chacun
d'entre eux pourra utiliser. Un mot-clé qui
limite le nombre d'utilisateurs
distants et de terminaux X en simultané est pseudo-device pty
16
. Avec FreeBSD 5.X, vous n'avez pas
à vous soucier de ce nombre puisque le pilote
pty(4) est capable d'« auto-clonage »,
vous devez donc utiliser la ligne device
pty
dans votre fichier de configuration.
La variable sysctl kern.ipc.somaxconn
limite la taille de la file d'attente acceptant les
nouvelles connexions TCP. La valeur par défaut de
128
est généralement trop
faible pour une gestion robuste des nouvelles connexions
dans un environnement de serveur web très
chargé. Pour de tels environnements, il est
recommandé d'augmenter cette valeur à
1024
ou plus. Le « daemon »
en service peut de lui-même limiter la taille de la
file d'attente (e.g. sendmail(8), ou
Apache) mais disposera, la
plupart du temps, d'une directive dans son fichier de
configuration pour ajuster la taille de la file d'attente.
Les files d'attentes de grandes tailles sont plus
adaptées pour éviter les attaques par
déni de service (DoS).
L'literal du noyau NMBCLUSTERS
fixe la
quantité de « Mbuf »;s disponibles pour le
système. Un serveur à fort trafic avec un nombre faible
de « Mbuf »;s sous-emploiera les capacités de FreeBSD.
Chaque “cluster” représente approximativement 2 Ko
de mémoire, donc une valeur de 1024 représente 2
mégaoctets de mémoire noyau réservée
pour les tampons réseau. Un simple calcul peut
être fait pour déterminer combien sont
nécessaires. Si vous avez un serveur web qui culmine à
1000 connexions simultanées, et que chaque connexion
consomme un tampon de réception de 16Ko et un tampon
d'émission de 16 Ko, vous avez approximativement besoin
de 32 Mo de tampon réseau pour couvrir les besoin du
serveur web. Un bon principe est de multiplier ce nombre
par 2, soit 2x32 Mo / 2 Ko = 64 Mo / 2 Ko =32768.
Nous recommandons des valeurs comprises entre 4096 et 32768
pour les machines avec des quantités de mémoire
plus élevées. Vous ne devriez, dans aucun
circonstance, spécifier de valeur élevée
arbitraire pour ce paramètre étant donné
que cela peut être à l'origine d'un plantage au
démarrage. L'option -m
de
netstat(1) peut être utilisée pour observer
l'utilisation des « clusters ».
La variable kern.ipc.nmbclusters
configurable au niveau du chargeur est utilisée pour
ajuster cela au démarrage. Seules les anciennes
versions de FreeBSD vous demanderont d'utiliser l'option de
configuration du noyau NMBCLUSTERS
.
Pour les serveurs chargés qui font une utilisation
intensive de l'appel système sendfile(2), il peut
être nécessaire d'augmenter le nombre de tampons
sendfile(2) par l'intermédiaire de l'option de
configuration du noyau NSFBUFS
ou en fixant
sa valeur dans le fichier
/boot/loader.conf
(consultez la page de
manuel loader(8) pour plus de détails). Un
indicateur de la nécessité d'ajuster ce
paramètre est lorsque des processus sont dans
l'état sfbufa
. La variable sysctl
kern.ipc.nsfbufs
est un aperçu en
lecture seule de la variable du noyau. Ce paramètre
s'ajuste de façon optimale avec
kern.maxusers
, il peut être cependant
nécessaire de l'ajuster en fonction des besoins.
Même si une « socket » a
été marquée comme étant
non-bloquante, un appel de sendfile(2) sur la
« socket » non-bloquante peut résulter en un
blocage de l'appel sendfile(2) jusqu'à ce que
suffisamment de struct sf_buf
soient
libérées.
Les variables net.inet.ip.portrange.*
contrôlent les intervalles de ports automatiquement
alloués aux « socket »s TCP et UDP. Il y
a trois intervalles: un intervalle bas, un intervalle par
défaut, et intervalle un haut. La plupart des
programmes réseau utilisent l'intervalle par
défaut qui est contrôlé par
net.inet.ip.portrange.first
et
net.inet.ip.portrange.last
, qui ont pour
valeur par défaut respectivement 1024 et 5000. Ces
intervalles de ports sont utilisés pour les
connexions sortantes, et il est possible de se trouver
à court de ports dans certaines conditions. Cela
arrive le plus souvent quand votre système fait
tourner un proxy web très chargé.
L'intervalle de ports n'est pas un problème quand
vous exécutez des serveurs qui ne gèrent
principalement que des connexions entrantes, comme un server
web classique, ou qui ont un nombre de connexions sortantes
limitées comme un relai de messagerie. Pour les cas
où vous risquez d'être à court de ports,
il est recommandé d'augmenter
légèrement
net.inet.ip.portrange.last
. Une valeur
de 10000
, 20000
ou
30000
doit être suffisante. Vous
devriez également penser au problème du
coupe-feu lors du changement de l'intervalle des ports.
Certains coupes-feu peuvent bloquer de grands intervalles de
ports (en général les ports inférieurs)
et s'attendent à ce que les systèmes utilisent
les intervalles supérieurs pour les connexions
sortantes — pour cette raison il n'est pas conseillé
de diminuer
net.inet.ip.portrange.first
.
La limitation du produit délai-bande passante TCP
est semblable au TCP/Vegas sous NetBSD. Elle peut
être activée en positionnant à
1
la variable
net.inet.tcp.inflight.enable
. Le
système tentera alors de calculer le produit
délai-bande passante pour chaque connexion et
limitera la quantité de données en attente
à la quantité juste nécessaire au
maintient d'un flux de sortie optimal.
Cette fonctionnalité est utile si vous diffusez
des données par l'intermédiaire de modems, de
connexions Ethernet Gigabit, ou même de liaisons hauts
débits WAN (ou toute autre liaison avec un produit
délai-bande passante élevé), tout
particulièrement si vous utilisez également le
dimensionnement des fenêtres d'émission ou que
vous avez configuré une fenêtre
d'émission importante. Si vous activez cette option,
vous devriez également vous assurer que
net.inet.tcp.inflight.debug
est
positionnée à 0
(désactive le débogage), et pour une
utilisation en production, fixer
net.inet.tcp.inflight.min
à au
moins 6144
peut être
bénéfique. Notez, cependant, que fixer des
minima élevés peut désactiver la
limitation de bande passante selon la liaison. La fonction
de limitation diminue la quantité de données
accumulées dans les files d'attente
intermédiaire de routage et de commutation, et
diminue également la quantité de
données présentes dans les files d'attente de
l'interface de la machine locale. Avec moins de paquets
dans les files d'attente, les connexions interactives, tout
particulièrement sur des modems lents, seront en
mesure de fonctionner avec des temps
d'aller-retour plus faible. Mais cette
fonctionnalité n'affecte que la transmission de
données (transmission côté serveur).
Ceci n'a aucun effet sur la réception de
données (téléchargement).
Modifier net.inet.tcp.inflight.stab
n'est pas recommandé. Ce
paramètre est fixé par défaut à
la valeur 20, représentant au maximum 2 paquets
ajoutés à la fenêtre de calcul du
produit délai-bande passante. La fenêtre
supplémentaire est nécessaire pour stabiliser
l'algorithme et améliorer la réponse aux
changements de conditions, mais il peut en résulter
des temps de « ping » plus élevés
sur les liaisons lentes (mais cependant inférieurs
à ce que vous obtiendriez sans l'algorithme de
limitation). Dans de tels cas, vous pouvez essayer de
réduire ce paramètre à 15, 10, ou 5, et
vous pouvez avoir à réduire le
paramètre
net.inet.tcp.inflight.min
(par exemple
à 3500) pour obtenir l'effet désiré.
Ces paramètres ne doivent être réduits
qu'en dernier ressort.
Un vnode est la représentation interne d'un fichier ou d'un répertoire. Augmenter le nombre de vnodes disponibles pour le système d'exploitation diminue les accès disque. Cela est normalement géré par le système d'exploitation et n'a pas besoin d'être modifié. Dans certains cas où les accès aux disques sont un goulot d'étranglement pour le système et que ce dernier est à cours de vnodes, ce nombre aura besoin d'être augmenté. La quantité de RAM libre et inactive sera prise en compte.
Pour connaître le nombre de vnodes actuellement utilisés:
#
sysctl vfs.numvnodes
vfs.numvnodes: 91349Pour connaître le maximum de vnodes utilisables:
#
sysctl kern.maxvnodes
kern.maxvnodes: 100000Si l'utilisation actuelle des vnodes est proche du
maximum, augmenter de 1000 kern.maxvnodes
est probablement une bonne idée. Gardez un oeil sur
le nombre vfs.numvnodes
. S'il approche
à nouveau le maximum,
kern.maxvnodes
devra être
augmenté de manière plus conséquente.
Une modification dans votre utilisation de la mémoire
devrait être visible dans top(1). Une plus
grande quantité de mémoire devrait être
annoncée comme active.
[5] L'algorithme d'auto-ajustement fixe
maxusers
à une valeur égale
à la quantité de mémoire présente
sur le système, avec un minimum de 32 et un maximum de
384..
Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Pour toutes questions à propos de FreeBSD, lisez la
documentation avant de contacter
<questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez
<doc@FreeBSD.org>.