Serveur Apache HTTP Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

# Apache MPM : Directives Communes

Langues Disponibles: de | en | fr | ja | tr

Description: | Une série de directives implémentées par plusieurs modules multi-processus (MPM)
Statut: | MPM

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

### Voir aussi

- Commentaires

## Directive CoreDumpDirectory

Description: | Le répertoire dans lequel le serveur HTTP Apache va tenter de se positionner avant d'effectuer un vidage mémoire
Syntaxe: | `CoreDumpDirectory répertoire`
Défaut: | `Voir ci-dessous pour le répertoire par défaut`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`

Cette directive permet de définir le répertoire dans lequel Apache httpd va tenter de se positionner avant d'effectuer un vidage mémoire sur disque. Si votre système d'exploitation est configuré pour créer des fichiers de vidage mémoire dans le répertoire de travail des processus qui se sont crashés, `CoreDumpDirectory` est nécessaire pour définir un répertoire de travail autre que le répertoire par défaut `ServerRoot`, ce répertoire de travail ne devant pas être accessible en écriture par l'utilisateur sous lequel le serveur s'exécute.

Si vous avez besoin d'un vidage mémoire pour le débogage, vous pouvez utiliser cette directive pour le placer à un endroit différent. Cette directive n'a aucun effet si votre système d'exploitation n'est pas configuré pour créer des fichiers de vidage mémoire dans le répertoire de travail des processus qui se sont crashés.

### Vidages mémoire sous Linux

Si Apache httpd est démarré sous l'utilisateur root puis bascule vers un autre utilisateur, le noyau Linux désactive les vidages mémoire, même si le répertoire est accessible en écriture au processus. Apache httpd (versions 2.0.46 et supérieures) réactive les vidages mémoire sous Linux 2.4 et au delà, mais seulement si vous définissez une directive `CoreDumpDirectory`.

### Vidages mémoire sous BSD

Pour activer le vidage mémoire des exécutables suid sur les systèmes de style BSD (comme FreeBSD), définissez `kern.sugid_coredump` à 1.

### Signaux spécifiques

`CoreDumpDirectory` n'est traité qu'à la reception d'un certain nombre de signaux , SIGFPE, SIGILL, SIGABORT, SIGSEGV, et SIGBUS.

Sur certains systèmes d'exploitation, SIGQUIT provoque aussi un vidage mémoire, mais n'est pas traité par les directives `CoreDumpDirectory` ou `EnableExceptionHook`, si bien que la définition du répertoire d'enregistrement du vidage mémoire est entièrement dévolue au système d'exploitation.

## Directive EnableExceptionHook

Description: | Active un hook ("point d'accrochage logiciel") qui exécute des gestionnaires d'exception après un crash
Syntaxe: | `EnableExceptionHook On|Off`
Défaut: | `EnableExceptionHook Off`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`

Pour des raisons de sécurité, cette directive n'est disponible que si la compilation du serveur a été configurée avec l'option `--enable-exception-hook`. Elle permet d'activer un hook ("point d'accrochage logiciel") qui autorise certains modules externes à effectuer un branchement et accomplir telle ou telle action après le crash d'un processus enfant.

Deux modules, `mod_whatkilledus` et `mod_backtrace` utilisent ce hook. Veuillez vous référer à la page EnableExceptionHook de Jeff Trawick pour plus d'informations à leur sujet.

## Directive GracefulShutdownTimeout

Description: | Spécifie le délai maximum après lequel le serveur va s'arrêter dans le cas d'un arrêt "en douceur"
Syntaxe: | `GracefulShutdownTimeout seconds`
Défaut: | `GracefulShutdownTimeout 0`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`
Compatibilité: | Disponible dans les versions 2.2 et supérieures

La directive `GracefulShutdownTimeout` permet de spécifier le temps, en secondes, pendant lequel le serveur va continuer à fonctionner après avoir reçu un signal "graceful-stop" ("Arrêt en douceur"), afin de terminer le traitement des connexions en cours.

Définir cette valeur à zéro signifie au serveur d'attendre jusqu'à ce que toutes les requêtes en cours aient été traitées.

## Directive Listen

Description: | Les adresses IP et ports sur lesquels le serveur écoute
Syntaxe: | `Listen [adresse IP:]numéro port [protocole]`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpm_netware`, `mpmt_os2`
Compatibilité: | L'argument protocole est supporté depuis la version 2.1.5

La directive `Listen` permet de signifier à Apache httpd de ne se mettre à l'écoute que sur les adresses IP et ports spécifiés ; par défaut, le serveur répond aux requêtes en provenance de toutes les interfaces réseau. La directive `Listen` est dorénavant requise, et si elle est absente du fichier de configuration, le serveur refusera de démarrer. Ceci constitue un changement par rapport aux versions précédentes d'Apache httpd.

La directive `Listen` signifie au serveur de n'accepter les requêtes entrantes que vers le port ou le couple adresse-port spécifié. Si seulement un port est spécifié, le serveur se met à l'écoute sur ce port sur toutes les interfaces réseau. Si une adresse IP et un port sont spécifiés, le serveur va se mettre à l'écoute sur ce port sur l'interface réseau correspondant à l'adresse IP.

On peut utiliser autant de directives `Listen` que nécessaire pour spécifier plusieurs adresses et/ou ports à écouter. Le serveur répondra aux requêtes vers tous les adresses et ports spécifiés.

Par exemple, pour que le serveur accepte les connexions sur les ports 80 et 8000, utilisez :

    Listen 80
    Listen 8000

Pour que le serveur accepte les connexions sur deux interfaces et ports particuliers, spécifiez :

    Listen 192.170.2.1:80
    Listen 192.170.2.5:8000

Les adressee IPv6 doivent être entourées de crochets, comme dans l'exemple suivant :

    Listen [2001:db8::a00:20ff:fea7:ccea]:80

L'argument optionnel protocole n'est pas nécessaire dans la plupart des configurations. S'il est absent, `https` est la valeur par défaut pour le port 443 et `http` l'est pour tous les autres ports. L'argument protocole sert à déterminer quel module doit traiter une requête, et à appliquer des optimisations spécifiques à certains protocoles à l'aide de la directive `AcceptFilter`.

La spécification d'un protocole n'est nécessaire que si vous utilisez des ports non standards. Par exemple, pour configurer un site en `https` sur le port 8443 :

    Listen 192.170.2.1:8443 https

### Condition d'erreur

Plusieurs directives `Listen` pour les mêmes adresse IP/port vont provoquer l'envoi d'un message d'erreur `Address already in use`.

### Voir aussi

- Problèmes avec DNS
- Définition des adresses et ports qu'utilise le serveur HTTP Apache
- Autre discussion à propos du message d'erreur `Address already in use`, citant d'autres causes possibles.

## Directive ListenBackLog

Description: | Longueur maximale de la liste d'attente des connexions
Syntaxe: | `ListenBacklog backlog`
Défaut: | `ListenBacklog 511`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpm_netware`, `mpmt_os2`

La longueur maximale de la liste d'attente des connexions. En général, aucune modification n'est nécessaire, ni même souhaitable ; cependant, sur certains systèmes, il peut être nécessaire d'en augmenter la valeur en cas d'attaque TCP SYN flood (envoi en masse de requêtes SYN pour saturer le serveur). Voir le paramètre backlog de l'appel système `listen(2)`.

En fait, l'argument backlog sera souvent limité à une valeur inférieure en fonction du système d'exploitation. Notez aussi que de nombreux systèmes d'exploitation ne tiennent pas vraiment compte de la valeur spécifiée pour l'argument backlog, mais s'en inspirent seulement (et choisissent en général une valeur supérieure).

## Directive ListenCoresBucketsRatio

Description: | Rapport entre le nombre de coeurs de processeur activés et le nombre de segments d'écoute
Syntaxe: | `ListenCoresBucketsRatio ratio`
Défaut: | `ListenCoresBucketsRatio 0 (disabled)`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`
Compatibilité: | Disponible à partir de la version 2.4.13 du serveur HTTP Apache, avec un noyau supportant l'option de socket `SO_REUSEPORT`, et distribuant uniformément les nouvelles connexions aux sockets d'écoute des processus (ou threads) qui l'utilisent (par exemple Linux versions 3.9 et ultérieures, mais pas l'implémentation courante de `SO_REUSEPORT` par les plateformes de type BSD.

Vous pouvez utiliser la directive `ListenCoresBucketsRatio` pour spécifier un ratio entre le nombre de coeurs de CPU activés et le nombre de segments d'écoute (listeners' buckets) souhaités ; le serveur HTTP Apache va alors créer`num_cpu_cores / ratio` segments d'écoute, chacun contenant son propre socket d'écoute `Listen` sur le ou les mêmes ports ; chaque processus enfant sera associé à un seul segment d'écoute (avec une distribution de type round-robin des segments à la création des processus enfants).

### Définition du terme coeur de CPU activé ("online")

Sous Linux et BSD, un coeur de CPU peut être activé ou désactivé si Hotplug a été configuré ; la directive `ListenCoresBucketsRatio` doit donc tenir compte de ce paramètre pour calculer le nombre de segments d'écoute à créer.

La directive `ListenCoresBucketsRatio` peut améliorer le support de la montée en charge lorsque l'arrivée de nouvelles connexions est/devient un goulot d'étranglement. Le test de cette fonctionnalité avec des machines possédant un nombre de coeurs de CPU important a permit de constater une amélioration des performances significative et des temps de réponse plus courts.

Pour que cette fonctionnalité soit activée, le nombre de coeurs de CPU doit être égal au moins au double du ratio spécifié. Si vous spécifiez la valeur recommandée pour ratio, à savoir `8`, le nombre minimum de coeurs de processeurs disponibles sera alors de `16`. La valeur optimale de ratio permettant d'obtenir des performances maximales doit être calculée pour chaque système cible, en testant plusieurs valeurs et en observant les résultats.

## Directive MaxConnectionsPerChild

Description: | Limite le nombre de connexions qu'un processus enfant va traiter au cours de son fonctionnement
Syntaxe: | `MaxConnectionsPerChild number`
Défaut: | `MaxConnectionsPerChild 0`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpm_netware`, `mpmt_os2`
Compatibilité: | Disponible depuis la version 2.3.9 du serveur HTTP Apache. L'ancien nom `MaxRequestsPerChild` est encore supporté.

La directive `MaxConnectionsPerChild` permet de définir le nombre maximum de connexions qu'un processus enfant va pouvoir traiter au cours de son fonctionnement. Lorsqu'il a traité `MaxConnectionsPerChild` connexions, le processus enfant est arrêté. Si `MaxConnectionsPerChild` est définie à `0`, il n'y a plus aucune limite sur le nombre de connexions que le processus pourra traiter.

Définir `MaxConnectionsPerChild` à une valeur non nulle limite la quantité de mémoire qu'un processus peut consommer à cause de fuites (accidentelles) de mémoire.

## Directive MaxMemFree

Description: | Quantité maximale de mémoire que l'allocateur principal est autorisé à conserver sans appeler `free()`
Syntaxe: | `MaxMemFree KOctets`
Défaut: | `MaxMemFree 2048`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpm_netware`

La directive `MaxMemFree` permet de définir le nombre maximum de KOctets libres que tout allocateur est autorisé à conserver sans appeler `free()`. Dans les MPMs threadés, chaque thread possède son propre allocateur. Si elle est définie à 0, la quantité de mémoire libre que peut conserver un allocateur est illimitée.

## Directive MaxRequestWorkers

Description: | Nombre maximum de connexions pouvant être traitées simultanément
Syntaxe: | `MaxRequestWorkers nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`

La directive `MaxRequestWorkers` permet de fixer le nombre maximum de requêtes pouvant être traitées simultanément. Si la limite `MaxRequestWorkers` est atteinte, toute tentative de connexion sera normalement mise dans une file d'attente, et ceci jusqu'à un certain nombre dépendant de la directive `ListenBacklog`. Lorsqu'un processus enfant se libèrera suite à la fin du traitement d'une requête, la connexion en attente pourra être traitée à son tour.

Pour les serveurs non threadés (c'est à dire utilisant `prefork`), la directive `MaxRequestWorkers` définit alors le nombre maximum de processus enfants qui pourront être lancés simultanément pour traiter les requêtes. La valeur par défaut est `256` ; si vous l'augmentez, vous devez aussi augmenter la valeur de la directive `ServerLimit`.

Pour les serveur threadés et hybrides (utilisant par exemple `event` ou `worker`), `MaxRequestWorkers` définit alors le nombre total de threads qui seront disponibles pour servir les clients. Dans le cas des MPMs hybrides, la valeur par défaut est `16` (directive `ServerLimit`) multiplié par la valeur `25` (directive `ThreadsPerChild`). Par conséquent, pour affecter à la directive `MaxRequestWorkers` une valeur qui requiert plus de 16 processus, vous devez aussi augmenter la valeur de la directive `ServerLimit`.

Le nom de la directive `MaxRequestWorkers` était `MaxClients` avant la version 2.3.13. Cet ancien nom est encore supporté.

## Directive MaxSpareThreads

Description: | Nombre maximum de threads inactifs
Syntaxe: | `MaxSpareThreads nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `mpm_netware`, `mpmt_os2`

C'est le nombre maximum de threads inactifs. Les MPMs utilisent cette directive de différentes manières.

Pour `worker` et `event`, la définition par défaut est `MaxSpareThreads 250`. Ce MPM gère les threads inactifs au niveau du serveur. Si le serveur possède trop de threads inactifs, des processus enfants seront arrêtés jusqu'à ce que le nombre de threads inactifs repasse en dessous de cette limite.

Pour `mpm_netware`, la définition par défaut est `MaxSpareThreads 100`. Comme ce MPM n'exécute qu'un seul processus, le nombre de processus inactifs est surveillé au niveau du serveur.

`mpmt_os2` fonctionne de manière similaire à `mpm_netware`. Pour `mpmt_os2`, la valeur par défaut est `10`.

### Contraintes

La gamme de valeurs pour `MaxSpareThreads` est limitée. Apache httpd corrigera automatiquement cette valeur selon les règles suivantes :

- Avec `mpm_netware`, `MaxSpareThreads` doit être supérieure à `MinSpareThreads`.
- Avec `worker` et `event`, `MaxSpareThreads` doit être supérieure ou égale à la somme de `MinSpareThreads` et `ThreadsPerChild`.

### Voir aussi

- `MinSpareThreads`
- `StartServers`
- `MaxSpareServers`

## Directive MinSpareThreads

Description: | Nombre minimum de threads inactifs qui seront disponibles pour pouvoir traiter les pics de requêtes
Syntaxe: | `MinSpareThreads nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `mpm_netware`, `mpmt_os2`

C'est le nombre minimum de threads inactifs pour être en mesure de traiter les pics de requêtes. Les MPMs utilisent cette directive de différentes manières.

Avec `worker` et `event`, la définition par défaut est `MinSpareThreads 75`, et le nombre de threads inactifs est surveillé au niveau du serveur. Si le serveur ne possède pas assez de threads inactifs, des processus enfants sont créés jusqu'à ce que le nombre de threads inactifs repasse au dessus de nombre.

Avec `mpm_netware`, la définition par défaut est `MinSpareThreads 10` et, comme ce MPM n'exécute qu'un seul processus, le nombre de threads est surveillé au niveau du serveur.

`mpmt_os2` fonctionne de manière similaire à `mpm_netware`. Pour `mpmt_os2`, la valeur par défaut est `5`.

### Voir aussi

- `MaxSpareThreads`
- `StartServers`
- `MinSpareServers`

## Directive PidFile

Description: | Ficher dans lequel le serveur enregistre l'identificateur de processus du démon
Syntaxe: | `PidFile nom fichier`
Défaut: | `PidFile logs/httpd.pid`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpmt_os2`

La directive `PidFile` permet de définir le ficher dans lequel le serveur enregistre l'identificateur de processus du démon. Si le chemin du fichier n'est pas absolu, il est considéré comme relatif au chemin défini par la directive `ServerRoot`.

### Exemple

    PidFile /var/run/apache.pid

Il est souvent utile de pouvoir envoyer un signal au serveur afin qu'il ferme et ouvre à nouveau ses journaux d'`erreur` et de `transfert`, et recharge son fichier de configuration. Pour ce faire, on envoie un signal SIGHUP (kill -1) à l'identificateur de processus enregistré dans le fichier défini par la directive `PidFile`.

La directive `PidFile` fait l'objet des mêmes avertissements que ceux concernant le chemin d'enregistrement des fichiers journaux et la sécurité.

### Note

Depuis la version 2 du serveur HTTP Apache, nous recommandons de n'utiliser que le script `apachectl`, ou le script de démarrage fourni avec votre système d'exploitation pour (re)démarrer ou arrêter le serveur.

## Directive ReceiveBufferSize

Description: | Taille du tampon TCP en entrée
Syntaxe: | `ReceiveBufferSize octets`
Défaut: | `ReceiveBufferSize 0`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpm_netware`, `mpmt_os2`

Le serveur va fixer la taille du tampon TCP en entrée au nombre d'octets spécifié.

Si la directive est définie à `0`, le serveur va utiliser la valeur par défaut adoptée par le système d'exploitation.

## Directive ScoreBoardFile

Description: | Chemin du fichier où sont stockées les données concernant la coordination des processus enfants
Syntaxe: | `ScoreBoardFile chemin fichier`
Défaut: | `ScoreBoardFile logs/apache_runtime_status`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`

Le serveur HTTP Apache utilise un tableau de bord pour la communication entre le processus parent et les processus enfants. Pour faciliter cette communication, certaines architectures nécessitent un fichier. En l'absence de cette directive, donc si aucun nom de fichier n'est spécifié, Apache httpd tentera tout d'abord de créer un tableau uniquement en mémoire (en utilisant la mémoire partagée anonyme) ; et si il n'y parvient pas, il tentera de créer un fichier sur disque (en utilisant la mémoire partagée à base de fichier). Si cette directive est utilisée, Apache httpd créera systématiquement un fichier sur disque.

### Exemple

    ScoreBoardFile /var/run/apache_runtime_status

Une mémoire partagée sous forme de fichier est utile pour les applications tierces qui nécessitent un accès direct au tableau de bord des processus.

Si vous utilisez un `ScoreBoardFile`, vous pourrez constater une amélioration des performances en le plaçant sur un disque virtuel en RAM. Assurez-vous cependant de tenir compte des mêmes avertissements que ceux concernant le chemin du fichier journal et la sécurité.

### Voir aussi

- Arrêter et redémarrer le serveur HTTP Apache

## Directive SendBufferSize

Description: | Taille du tampon TCP en sortie
Syntaxe: | `SendBufferSize octets`
Défaut: | `SendBufferSize 0`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpm_winnt`, `mpm_netware`, `mpmt_os2`

Définit la taille du tampon TCP en sortie avec le nombre d'octets spécifié. Ceci s'avère souvent très utile pour augmenter les valeurs par défaut standards du passé des systèmes d'exploitation pour les transmissions à grande vitesse et haute densité (c'est à dire de l'ordre de 100ms comme sur les liaisons rapides transcontinentales).

Si la directive est définie à `0`, le serveur va utiliser la valeur par défaut adoptée par le système d'exploitation.

L'amélioration des performances des connexions à grande vitesse et à temps de latence élevé, peut nécessiter une intervention au niveau de la configuration de votre système d'exploitation.

Sous certains systèmes d'exploitation, la modification du comportement TCP via une augmentation de la valeur de `SendBufferSize` risque de ne pas être perceptible, si la directive `EnableSendfile` n'est pas définie à OFF. Cette interaction ne s'applique qu'aux fichiers statiques.

## Directive ServerLimit

Description: | Limite supérieure de la définition du nombre de processus
Syntaxe: | `ServerLimit nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`

Avec le MPM `prefork`, cette directive définit le nombre maximum que l'on peut affecter à la directive `MaxRequestWorkers`, et ceci pour la durée de vie du processus Apache httpd. Avec les MPMs `worker` et `event`, cette directive, en combinaison avec `ThreadLimit`, définit le nombre maximum que l'on peut affecter à `MaxRequestWorkers`, et ceci pour la durée de vie du processus Apache httpd. Au cours d'un redémarrage, vous pouvez modifier la valeur de la directive `MaxRequestWorkers`, alors que toute tentative de modification de la valeur de la directive `ServerLimit` sera ignorée.

Cette directive doit être utilisée avec précaution. Si `ServerLimit` est définie à une valeur beaucoup plus grande que nécessaire, de la mémoire partagée supplémentaire sera inutilement allouée. Si à la fois `ServerLimit` et `MaxRequestWorkers` possèdent des valeurs supérieures à ce que le système peut supporter, ce dernier peut devenir instable ou Apache httpd peut tout simplement refuser de démarrer.

Avec les MPMs `prefork` et `event`, n'utilisez cette directive que si vous devez définir `MaxRequestWorkers` à une valeur supérieure à 256 (valeur par défaut). N'affectez pas à la directive `ServerLimit` une valeur supérieure à celle que vous avez prévu d'affecter à la directive `MaxRequestWorkers`.

Avec `worker`, n'utilisez cette directive que si la définition de vos directives `MaxRequestWorkers` et `ThreadsPerChild` nécessitent plus de 16 processus serveurs (valeur par défaut). N'affectez pas à la directive `ServerLimit` une valeur supérieure au nombre de processus requis pour la définition des directives `MaxRequestWorkers` et `ThreadsPerChild`.

### Note

Il existe une limite de `ServerLimit 20000` codée en dur dans le serveur (200000 pour le MPM `prefork`). Ceci est censé éviter les effets désastreux que pourrait provoquer une faute de frappe. Pour dépasser cette limite, vous devez modifier la valeur de MAX_SERVER_LIMIT dans le fichier source du mpm et recompiler le serveur.

### Voir aussi

- Arrêter et redémarrer le serveur HTTP Apache

## Directive StartServers

Description: | Nombre de processus enfants du serveur créés au démarrage
Syntaxe: | `StartServers nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `prefork`, `mpmt_os2`

La directive `StartServers` permet de définir le nombre de processus enfants du serveur créés au démarrage. Comme le nombre de processus est contrôlé dynamiquement en fonction de la charge (voir `MinSpareThreads`, `MaxSpareThreads`, `MinSpareServers`, `MaxSpareServers`), il n'est en général pas nécessaire d'ajuster ce paramètre.

La valeur par défaut diffère d'un MPM à l'autre. Pour `worker` et `event`, la définition par défaut est `StartServers 3` ; la valeur par défaut est `5` pour `prefork` et `2` pour `mpmt_os2`.

## Directive StartThreads

Description: | Nombre de threads créés au démarrage
Syntaxe: | `StartThreads nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `mpm_netware`

C'est le nombre de threads créés au démarrage du serveur. Comme le nombre de threads est contrôlé dynamiquement en fonction de la charge (voir `MinSpareThreads`, `MaxSpareThreads`, `MinSpareServers`, `MaxSpareServers`), il n'est en général pas nécessaire d'ajuster ce paramètre.

Pour `mpm_netware`, la définition par défaut est `StartThreads 50` et, comme il n'y a qu'un processus, il s'agit du nombre total de threads créés au démarrage pour servir les requêtes.

## Directive ThreadLimit

Description: | Le nombre de threads maximum que l'on peut définir par processus enfant
Syntaxe: | `ThreadLimit nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `mpm_winnt`

Cette directive permet de définir le nombre maximum que l'on peut affecter à la directive `ThreadsPerChild` pour la durée de vie du processus Apache httpd. La directive `ThreadsPerChild` peut être modifiée au cours d'un redémarrage jusqu'à la valeur de la directive `ThreadLimit`, mais toute tentative de modification de la directive `ThreadLimit` au cours d'un redémarrage sera ignorée.

L'utilisation de cette directive doit faire l'objet de précautions particulières. Si `ThreadLimit` est définie à une valeur très supérieure à la directive `ThreadsPerChild`, de la mémoire partagée supplémentaire sera inutilement allouée. Si les directives `ThreadLimit` et `ThreadsPerChild` sont définies à des valeurs supérieures à ce que le système peut supporter, ce dernier peut devenir instable, ou Apache httpd peut tout simplement refuser de démarrer. Ne définissez pas cette directive à une valeur supérieure à la valeur maximale que vous pensez affecter à la directive `ThreadsPerChild` pour le processus Apache httpd en cours d'exécution.

La valeur par défaut de la directive `ThreadLimit` est `1920` avec `mpm_winnt`, et `64` avec les autres MPMs.

### Note

Il existe une limite de `ThreadLimit 20000` (ou `ThreadLimit 100000` avec `event`, `ThreadLimit 15000` avec `mpm_winnt`) codée en dur dans le serveur. Ceci est censé éviter les effets désastreux que pourrait provoquer une faute de frappe. Pour dépasser cette limite, vous devez modifier la valeur de MAX_THREAD_LIMIT dans le fichier source du mpm et recompiler le serveur.

## Directive ThreadsPerChild

Description: | Nombre de threads créés par chaque processus enfant
Syntaxe: | `ThreadsPerChild nombre`
Défaut: | `Voir ci-dessous pour plus de détails`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `mpm_winnt`

Cette directive permet de définir le nombre de threads que va créer chaque processus enfant. Un processus enfant crée ces threads au démarrage et n'en crée plus d'autres par la suite. Si l'on utilise un MPM comme `mpm_winnt` qui ne lance qu'un processus enfant, ce nombre doit être suffisamment grand pour supporter la charge du serveur. Avec un MPM comme `worker` qui lance plusieurs processus enfants, c'est le nombre total de threads qui doit être suffisamment grand pour supporter la charge du serveur.

La valeur par défaut de la directive `ThreadsPerChild` est `64` avec `mpm_winnt`, et `25` avec les autres MPMs.

## Directive ThreadStackSize

Description: | La taille en octets de la pile qu'utilisent les threads qui traitent les connexions clients
Syntaxe: | `ThreadStackSize taille`
Défaut: | `65536 sous NetWare; varie en fonction des autres systèmes d'exploitation`
Contexte: | configuration du serveur
Statut: | MPM
Module: | `event`, `worker`, `mpm_winnt`, `mpm_netware`, `mpmt_os2`
Compatibilité: | Disponible dans les versions 2.1 et supérieures du serveur HTTP Apache

La directive `ThreadStackSize` permet de définir la taille de la pile (pour les données propres) qu'utilisent les threads qui traitent les connexions clients en faisant appel à des modules. Dans la plupart des cas, la valeur par défaut de la taille de la pile du système d'exploitation convient, mais il existe certaines situations où il peut s'avérer nécessaire de l'ajuster :

- Sur les plates-formes qui possèdent une valeur par défaut de taille de la pile relativement petite (par exemple HP-UX), Apache httpd peut se crasher si l'on utilise certains modules tiers qui possèdent un quantité de données propres stockées relativement importante. Il se peut que ces mêmes modules fonctionnent correctement sur d'autres plate-formes où la valeur par défaut de la taille de la pile est supérieure. Ce type de crash peut être evité en définissant `ThreadStackSize` à une valeur supérieure à la valeur par défaut du système d'exploitation. Ce type d'ajustement n'est nécessaire que si le fournisseur du module tiers en fait mention, ou si le diagnostic d'un crash d'Apache httpd indique que la taille de la pile était trop petite.
- Sur les plates-formes où la taille par défaut de la pile des threads est sensiblement supérieure à la taille nécessaire pour la configuration du serveur web, il est possible de disposer d'un plus grand nombre de threads par processus enfant si la directive `ThreadStackSize` est définie à une valeur inférieure à la valeur par défaut du système d'exploitation. Cependant, ce type d'ajustement ne doit être effectué que dans un environnement de test permettant de qualifier le serveur web au maximum de ses possibilités, car il peut arriver, dans de rares cas, que des requêtes nécessitent une taille de pile supérieure pour pouvoir être traitées. La taille minimale requise pour la pile dépend fortement des modules utilisés, mais toute modification dans la configuration du serveur web peut invalider la définition courante de la directive `ThreadStackSize`.
- Sous Linux, cette directive ne peut être utilisée que pour augmenter la valeur par defaut de la taille de la pile, car l'appel système sous-jacent utilise cette valeur comme taille de pile minimale. C'est la limite logicielle (souvent élevée) pour `ulimit -s` (8Mo si aucune limite) qui est utilisée comme taille de pile par défaut.

Il est recommandé de ne pas réduire `ThreadStackSize`, à moins qu'un grand nombre de threads par processus enfant ne soit nécessaire. Sur certaines plates-formes (y compris Linux), une valeur de 128000 est déjà trop basse et provoque des crashes avec certains modules courants.

Langues Disponibles: de | en | fr | ja | tr

## Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.