kern.maxfiles
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[1]. 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.
Note : 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.
kern.ipc.somaxconn
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.
Important : 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.
net.inet.ip.portrange.*
Les variables net.inet.ip.portrange.*
contrôlent les
intervalles de ports automatiquement alloués aux sockets 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.
kern.maxvnodes
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: 91349
Pour connaître le maximum de vnodes utilisables:
# sysctl kern.maxvnodes kern.maxvnodes: 100000
Si 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.
[1] |
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.. |
Précédent | Sommaire | Suivant |
Optimiser les disques | Niveau supérieur | Ajouter de l'espace de pagination |
Ce document, ainsi que d'autres peut être téléchargé sur 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>.