Serveur HTTP Apache Version 2.5
Description: | Une série de directives implémentées par plusieurs modules multi-processus (MPM) |
---|---|
Statut: | MPM |
Description: | Traite certaines erreurs lors de l'acceptation d'une nouvelle connexion comme non fatales pour le processus httpd. |
---|---|
Syntaxe: | AcceptErrorsNonFatal ON |
Défaut: | OFF (les erreurs ECONNREFUSED, ECONNABORTED, ECONNRESET entraînent
alors la fermeture du processus httpd) |
Contexte: | configuration globale |
Statut: | MPM |
Module: | event , worker , prefork |
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache |
La directive AcceptErrorsNonFatal
permet de
modifier le comportement du serveur lorsque certaines erreurs
rares apparaissent lors de l'acceptation d'une nouvelle connexion avec un
client. Par défaut, le processus enfant qui traite la requête se terminera
en douceur pratiquement chaque fois qu'une erreur de socket apparaît au
cours de l'appel système accept(), ceci dans le but de s'assurer qu'un
processus enfant potentiellement endommagé ne tentera pas de prendre en
compte de nouvelles connexions.
Lorsque la directive AcceptErrorsNonFatal
est à
"ON", le processus n'enclenchera pas sa procédure d'arrêt si
l'erreur accept() est ECONNREFUSED, ECONNABORTED, ou ECONNRESET.
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 globale |
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.
Utiliser cette directive sous Linux peut permettre aux autres processus
du système s'exécutant avec les même privilèges (comme les scripts CGI) de
se rattacher aux processus httpd enfants via l'appel système
ptrace
. La protection contre certaines attaques engageant la
sécurité peut s'en trouver affectée. Il est par conséquent déconseillé
d'utiliser cette directive sur les systèmes en production.
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
.
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.
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.
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 globale |
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.
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 globale |
Statut: | MPM |
Module: | event , worker , prefork |
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.
Description: | Les adresses IP et ports sur lesquels le serveur écoute |
---|---|
Syntaxe: | Listen [adresse IP:]numéro port
[protocole] |
Contexte: | configuration globale |
Statut: | MPM |
Module: | event , worker , prefork , mpm_winnt , mpm_netware , mpmt_os2 |
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
Listen
pour les mêmes
adresse IP/port vont provoquer l'envoi d'un message d'erreur
Address already in use
.
Description: | Longueur maximale de la liste d'attente des connexions |
---|---|
Syntaxe: | ListenBackLog backlog |
Défaut: | ListenBackLog 511 |
Contexte: | configuration globale |
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).
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 globale |
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éernum_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).
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.
Cette directive influence le calcul des valeurs limites inférieures de
MinSpareThreads
et MaxSpareThreads
. En effet, pour accepter les
connexions de manière optimale, le nombre de processus enfants doit être un
multiple du nombre de segments d'écoute.
Listen
ers ou serveurs HTTP
Apache partagent la même adresse IP et portLa définition de l'option SO_REUSEPORT
pour les sockets
d'écoute permet à plusieurs processus (partageant le même EUID
,
par exemple root
) de se rattacher à la même adresse IP et port,
sans obtenir l'erreur de rattachement que le système génère habituellement
lorsque ce cas se produit.
Cela signifie aussi que plusieurs instances d'Apache httpd configurées
avec le même IP:port
et avec une valeur
ListenCoresBucketsRatio
positive pourraient démarrer
sans erreur, et fonctionner ensuite avec une répartition uniforme des
connexions entrantes sur ces différentes instances (ce n'est PAS une
recommandation et ne constitue pas un usage approprié à tous les cas, mais
juste un avertissement sur le fait qu'un véritable problème de rattachement
multiple à un IP:port
pourrait alors être occulté).
Au sein d'une même instance, Apache httpd vérifie la présence de
directives Listen
multiples avec la même adresse IP
(ou nom d'hôte) et le même port, et refuse de démarrer si c'est le cas, ce
qui permet d'éviter la création de segments d'écoute dupliqués qui seraient
du coup inutiles et affecteraient les performances. Cependant, il ne peut
pas (et n'essaiera pas de le faire) intercepter tous les cas possibles de
recouvrement (comme un nom d'hôte correspondant à une adresse IP utilisée
quelque part ailleurs).
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 globale |
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.
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 globale |
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.
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 globale |
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é.
Description: | Nombre maximum de threads inactifs |
---|---|
Syntaxe: | MaxSpareThreads nombre |
Défaut: | Voir ci-dessous pour plus de détails |
Contexte: | configuration globale |
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. Des
processus/threads supplémentaires sont susceptibles d'être créés si
ListenCoresBucketsRatio
est
activée.
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
.
La gamme de valeurs pour MaxSpareThreads
est limitée. Apache httpd corrigera automatiquement cette valeur selon
les règles suivantes :
mpm_netware
, MaxSpareThreads
doit être supérieure à MinSpareThreads
.worker
et event
, MaxSpareThreads
doit être supérieure ou égale à la somme de MinSpareThreads
et ThreadsPerChild
.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 globale |
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. Des processus/threads supplémentaires peuvent
être créés si ListenCoresBucketsRatio
est activée.
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
.
Description: | Ficher dans lequel le serveur enregistre l'identificateur de processus du démon |
---|---|
Syntaxe: | PidFile nom fichier |
Défaut: | PidFile httpd.pid |
Contexte: | configuration globale |
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 DefaultRuntimeDir
.
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é.
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.
Description: | Taille du tampon TCP en entrée |
---|---|
Syntaxe: | ReceiveBufferSize octets |
Défaut: | ReceiveBufferSize 0 |
Contexte: | configuration globale |
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.
Description: | Chemin du fichier où sont stockées les données concernant la coordination des processus enfants |
---|---|
Syntaxe: | ScoreBoardFile file-path |
Défaut: | ScoreBoardFile apache_runtime_status |
Contexte: | configuration globale |
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.
Si file-path n'est pas un chemin absolu, il sera relatif à la
valeur spécifiée par la directive DefaultRuntimeDir
.
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é.
Description: | Taille du tampon TCP en sortie |
---|---|
Syntaxe: | SendBufferSize octets |
Défaut: | SendBufferSize 0 |
Contexte: | configuration globale |
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.
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 globale |
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. Avec le MPM event
, cette
directive permet aussi de définir combien de processus anciens peuvent
continuer à s'exécuter pour terminer le traitement des connexions ouvertes.
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
.
Avec le MPM event
, augmentez la valeur de cette
directive si le nombre de processus défini par les directives MaxRequestWorkers
et ThreadsPerChild
augmenté du nombre de processus
en procédure d'arrêt "graceful" est supérieur à 16 (valeur par défaut).
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.
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 globale |
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
.
Description: | Nombre de threads créés au démarrage |
---|---|
Syntaxe: | StartThreads nombre |
Défaut: | Voir ci-dessous pour plus de détails |
Contexte: | configuration globale |
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.
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 globale |
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.
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.
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 globale |
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.
La valeur de la directive ThreadsPerChild
ne peut
pas dépasser la valeur de la directive ThreadLimit
. Si on spécifie une valeur
supérieure, elle sera automatiquement réduite au démarrage du serveur et un
avertissement sera enregistré dans le journal. La relation entre ces deux
directives est expliquée dans la documentation de la directive ThreadLimit
.
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 globale |
Statut: | MPM |
Module: | event , worker , mpm_winnt , mpm_netware , mpmt_os2 |
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
:
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.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
.ulimit -s
(8Mo si aucune limite) qui est
utilisée comme taille de pile par défaut.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.