Apache MPM : Directives Communes

Directive CoreDumpDirectory

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.

Directive EnableExceptionHook

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

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

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

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

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

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

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.

Directive MaxConnectionsPerChild

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

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

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

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.

Voir aussi

• MinSpareThreads
• StartServers
• MaxSpareServers

Directive MinSpareThreads

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.

Voir aussi

• MaxSpareThreads
• StartServers
• MinSpareServers

Directive PidFile

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.

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

Directive ReceiveBufferSize

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

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.

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

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.

Directive ServerLimit

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 le nombre de processus anciens du serveur pouvant 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.

Voir aussi

• Arr�ter et red�marrer le serveur HTTP Apache

Directive StartServers

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

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

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.

Directive ThreadsPerChild

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

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.