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>.