11.13. Optimisation des limitations du noyau

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

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

11.13.2.1. net.inet.ip.portrange.*

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.

11.13.2.2. Le produit délai-bande passante TCP

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.

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