Various updates.
This commit is contained in:
Marc Fonvieille
parent
f0a31a64e3
commit
725347a499
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=22214
1 changed files with 319 additions and 12 deletions
|
|
@ -3,8 +3,7 @@
|
|||
The FreeBSD French Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$Id: chapter.sgml,v 1.8 2004-01-24 10:30:12 blackend Exp $
|
||||
Original revision: 1.79
|
||||
Original revision: 1.91
|
||||
-->
|
||||
|
||||
<chapter id="config-tuning">
|
||||
|
|
@ -40,7 +39,9 @@
|
|||
<sect1 id="config-synopsis">
|
||||
<title>Synopsis</title>
|
||||
|
||||
<indexterm><primary>configuration/optimisation du
|
||||
<indexterm><primary>configuration du
|
||||
système</primary></indexterm>
|
||||
<indexterm><primary>optimisation du
|
||||
système</primary></indexterm>
|
||||
|
||||
<para>La configuration correcte d'un système peut sensiblement
|
||||
|
|
@ -67,6 +68,10 @@
|
|||
<filename>rc.conf</filename> et des fichiers de démarrage
|
||||
<filename>/usr/local/etc/rc.d</filename>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Comment configurer et tester une carte
|
||||
réseau.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Comment configurer des hôtes virtuels sur vos
|
||||
périphériques réseau.</para>
|
||||
|
|
@ -1344,7 +1349,7 @@ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen>
|
|||
avoir une adresse qui représente correctement le masque de
|
||||
réseau de votre réseau. Tout autre adresse appartenant
|
||||
à ce réseau devra avoir un masque de réseau
|
||||
avec chaque bit à 1.</para>
|
||||
avec chaque bit à <literal>1</literal>.</para>
|
||||
|
||||
<para>Par exemple, considérez le cas où
|
||||
l'interface <devicename>fxp0</devicename> est connectée à
|
||||
|
|
@ -1819,6 +1824,93 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
|
|||
faire des expériences pour le déterminer.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title><varname>vfs.write_behind</varname></title>
|
||||
|
||||
<indexterm>
|
||||
<primary><varname>vfs.write_behind</varname></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>La variable sysctl <varname>vfs.write_behind</varname> est
|
||||
positionnée par défaut à
|
||||
<literal>1</literal> (activée). Elle demande au
|
||||
système de fichiers d'effectuer les écritures
|
||||
lorsque des grappes complètes de données ont
|
||||
été collectées, ce qui se produit
|
||||
généralement lors de l'écriture
|
||||
séquentielle de gros fichiers. L'idée est
|
||||
d'éviter de saturer le cache tampon avec des tampons
|
||||
sales quand cela n'améliorera pas les performances d'E/S.
|
||||
Cependant, cela peut bloquer les processus et dans certaines
|
||||
conditions vous pouvez vouloir désactiver cette
|
||||
fonction.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title><varname>vfs.hirunningspace</varname></title>
|
||||
|
||||
<indexterm>
|
||||
<primary><varname>vfs.hirunningspace</varname></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>La variable sysctl <varname>vfs.hirunningspace</varname>
|
||||
détermine combien d'opérations d'écriture
|
||||
peuvent être mises en attente à tout moment au
|
||||
niveau des contrôleurs disques du système. La
|
||||
valeur par défaut est normalement suffisante mais sur les
|
||||
machines avec de nombreux disques, vous pouvez vouloir
|
||||
l'augmenter jusqu'à quatre ou cinq
|
||||
<emphasis>méga-octets</emphasis>. Notez que fixer une
|
||||
valeur trop élevée (dépassant la limite
|
||||
d'écriture du cache tampon) peut donner lieu à de
|
||||
très mauvaises performances. Ne fixez pas cette valeur
|
||||
à une valeur élevée arbitraire! Des
|
||||
valeurs d'écriture élevées peuvent ajouter
|
||||
des temps de latence aux opérations d'écriture
|
||||
survenant au même moment.</para>
|
||||
|
||||
<para>Il existent d'autres variables sysctl relatives aux caches
|
||||
tampons et aux pages VM. Nous ne recommandons pas de modifier
|
||||
ces valeurs. Depuis &os; 4.3, le système VM
|
||||
effectue un très bon travail d'auto-optimisation.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title><varname>vm.swap_idle_enabled</varname></title>
|
||||
|
||||
<indexterm>
|
||||
<primary><varname>vm.swap_idle_enabled</varname></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>La variable <varname>vm.swap_idle_enabled</varname> est
|
||||
utile dans le cas de systèmes multi-utilisateurs
|
||||
importants où il y a beaucoup d'utilisateurs s'attachant
|
||||
et quittant le système et de nombreux processus inactifs.
|
||||
De tels systèmes tendent à générer
|
||||
une pression assez importante et continue sur les
|
||||
réserves de mémoire libres. Activer cette
|
||||
fonction et régler l'hystéresis de
|
||||
libération de l'espace de pagination (en secondes
|
||||
d'inactivité) par l'intermédiaire des variables
|
||||
<varname>vm.swap_idle_threshold1</varname> et
|
||||
<varname>vm.swap_idle_threshold2</varname>, vous permet de
|
||||
diminuer la priorité des pages mémoire
|
||||
associées avec les processus inactifs plus rapidement
|
||||
qu'avec l'algorithme normal de libération. Cela aide le
|
||||
<quote>daemon</quote> de libération des pages. N'activez
|
||||
cette option que si vous en besoin, parce que la concession que
|
||||
vous faites est d'utiliser l'espace de pagination pour les pages
|
||||
mémoire plus tôt qu'à l'accoutumé,
|
||||
consommant par conséquent plus d'espace de pagination et
|
||||
de bande passante disque. Sur un petit système, cette
|
||||
option aura un effet limité mais dans le cas d'un
|
||||
système important qui fait appel à l'espace de
|
||||
pagination de façon modérée, cette option
|
||||
permettra au système VM de transférer l'ensemble
|
||||
des processus de et vers la mémoire
|
||||
aisément.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title><varname>hw.ata.wc</varname></title>
|
||||
|
||||
|
|
@ -1858,6 +1950,32 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
|
|||
<para>Pour plus d'informations, veuillez consulter la page de
|
||||
manuel &man.ata.4;.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title><literal>SCSI_DELAY</literal>
|
||||
(<varname>kern.cam.scsi_delay</varname>)</title>
|
||||
|
||||
<indexterm>
|
||||
<primary><literal>SCSI_DELAY</literal></primary>
|
||||
<secondary><varname>kern.cam.scsi_delay</varname></secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>L'option de configuration du noyau
|
||||
<literal>SCSI_DELAY</literal> peut être utilisée
|
||||
pour réduire le temps de démarrage du
|
||||
système. Le délai par défaut est important
|
||||
et peut être responsable de plus de <literal>15</literal>
|
||||
secondes d'attente lors du processus de démarrage.
|
||||
Réduire ce délai à <literal>5</literal>
|
||||
secondes est généralement suffisant (tout
|
||||
particulièrement avec les disques modernes). Les
|
||||
versions de &os; récentes (5.0 et suivantes) devraient
|
||||
utiliser l'option de démarrage
|
||||
<varname>kern.cam.scsi_delay</varname>. Cette option de
|
||||
démarrage et celle de configuration du noyau acceptent
|
||||
des valeurs en <emphasis>millisecondes</emphasis> et <emphasis>non pas</emphasis> en
|
||||
<emphasis>secondes</emphasis>.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="soft-updates">
|
||||
|
|
@ -2170,28 +2288,217 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
|
|||
valeur raisonnable par défaut basée sur la
|
||||
quantité de mémoire présente sur votre
|
||||
système.</para></note>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title><varname>kern.ipc.somaxconn</varname></title>
|
||||
|
||||
<indexterm>
|
||||
<primary><varname>kern.ipc.somaxconn</varname></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>La variable sysctl <varname>kern.ipc.somaxconn</varname>
|
||||
limite la taille de la file d'attente acceptant les
|
||||
nouvelles connexions TCP. La valeur par défaut de
|
||||
<literal>128</literal> est généralement trop
|
||||
faible pour une gestion robuste des nouvelles connexions
|
||||
dans un environement de serveur web très
|
||||
chargé. Pour de tels environnements, il est
|
||||
recommandé d'augmenter cette valeur à
|
||||
<literal>1024</literal> ou plus. Le <quote>daemon</quote>
|
||||
en service peut de lui-même limiter la taille de la
|
||||
file d'attente (e.g. &man.sendmail.8;, ou
|
||||
<application>Apache</application>) 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 (<abbrev>DoS</abbrev>).</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Limitations réseau</title>
|
||||
|
||||
<para>L'option du noyau <option>NMBCLUSTERS</option> fixe la
|
||||
quantité de “mbuf”s disponibles pour le
|
||||
<para>L'literal du noyau <literal>NMBCLUSTERS</literal> fixe la
|
||||
quantité de <quote>Mbuf</quote>;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 2KO
|
||||
de <quote>Mbuf</quote>;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 16KO, vous avez approximativement besoin
|
||||
de 32MO de tampon réseau pour couvrir les besoin du
|
||||
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 / 2KO = 64MO / 2KO =32768.</para>
|
||||
par 2, soit 2x32 Mo / 2 Ko = 64 Mo / 2 Ko =32768.
|
||||
Nous recommendons 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 <option>-m</option> de
|
||||
&man.netstat.1; peut être utilisée pour observer
|
||||
l'utilisation des <quote>clusters</quote>.</para>
|
||||
|
||||
<para>La variable <varname>kern.ipc.nmbclusters</varname>
|
||||
configurable au niveau du chargeur est utilisée pour
|
||||
ajuster cela au démarrage. Seules les anciennes
|
||||
versions de &os; vous demanderont d'utiliser l'option de
|
||||
configuration du noyau <literal>NMBCLUSTERS</literal>.</para>
|
||||
|
||||
<para>Pour les serveurs chargés qui font une utilisation
|
||||
intensive de l'appel système &man.sendfile.2;, il peut
|
||||
être nécessaire d'augmenter le nombre de tampons
|
||||
&man.sendfile.2; par l'intermédiaire de l'option de
|
||||
configuration du noyau <literal>NSFBUFS</literal> ou en fixant
|
||||
sa valeur dans le fichier
|
||||
<filename>/boot/loader.conf</filename> (consultez la page de
|
||||
manuel &man.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 <literal>sfbufa</literal>. La variable sysctl
|
||||
<varname>kern.ipc.nsfbufs</varname> est un aperçu en
|
||||
lecture seule de la variable du noyau. Ce paramètre
|
||||
s'ajuste de façon optimale avec
|
||||
<varname>kern.maxusers</varname>, il peut être cependant
|
||||
nécessaire de l'ajuster en fonction des besoins.</para>
|
||||
|
||||
<important>
|
||||
<para>Même si une <quote>socket</quote> a
|
||||
été marquée comme étant
|
||||
non-bloquante, un appel de &man.sendfile.2; sur la
|
||||
<quote>socket</quote> non-bloquante peut résulter en un
|
||||
blocage de l'appel &man.sendfile.2; jusqu'à ce que
|
||||
suffisament de <literal>struct sf_buf</literal> soient
|
||||
libérées.</para>
|
||||
</important>
|
||||
|
||||
<sect3>
|
||||
<title><varname>net.inet.ip.portrange.*</varname></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>net.inet.ip.portrange.*</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Les variables <varname>net.inet.ip.portrange.*</varname>
|
||||
contrôlent les intervalles de ports automatiquement
|
||||
alloués aux <quote>socket</quote>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
|
||||
<varname>net.inet.ip.portrange.first</varname> et
|
||||
<varname>net.inet.ip.portrange.last</varname>, 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
|
||||
<varname>net.inet.ip.portrange.last</varname>. Une valeur
|
||||
de <literal>10000</literal>, <literal>20000</literal> ou
|
||||
<literal>30000</literal> 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 est conseillé
|
||||
de diminuer
|
||||
<varname>net.inet.ip.portrange.first</varname>.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Le produit délai-bande passante TCP</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>limitation du produit délai-bande passante
|
||||
TCP</primary>
|
||||
<secondary><varname>net.inet.tcp.inflight_enable</varname></secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>La limitation du produit délai-bande passante TCP
|
||||
est semblable au TCP/Vegas sous NetBSD. Elle peut
|
||||
être activée en positionnant à
|
||||
<literal>1</literal> la variable
|
||||
<varname>net.inet.tcp.inflight_enable</varname>. 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.</para>
|
||||
|
||||
<para>Cette fonctionnalité est utile si vous diffusez
|
||||
des données par l'intermédiare 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
|
||||
<varname>net.inet.tcp.inflight_debug</varname> est
|
||||
positionnée à <literal>0</literal>
|
||||
(désactive le débogage), et pour une
|
||||
utilisation en production, fixer
|
||||
<varname>net.inet.tcp.inflight_min</varname> à au
|
||||
moins <literal>6144</literal> peut être
|
||||
bénéfique. Notez, cependant, que fixer des
|
||||
minimas é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 <emphasis>temps
|
||||
d'aller-retour</emphasis> 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).
|
||||
</para>
|
||||
|
||||
<para>Modifier <varname>net.inet.tcp.inflight_stab</varname>
|
||||
n'est <emphasis>pas</emphasis> 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 <quote>ping</quote> 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
|
||||
<varname>net.inet.tcp.inflight_min</varname> (par exemple
|
||||
à 3500) pour obtenir l'effet désiré.
|
||||
Ces paramètres ne doivent être réduits
|
||||
qu'en dernier ressort.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue