Dimensionnement mémoire d'un serveur web Apache - Historique des versions

Lea : Lea a déplacé la page Dimensionnement d'un serveur web Apache vers Dimensionnement mémoire d'un serveur web Apache

2023-12-04T20:36:33Z

Lea a déplacé la page Dimensionnement d'un serveur web Apache vers Dimensionnement mémoire d'un serveur web Apache

← Version précédente	Version du 4 décembre 2023 à 20:36
(Aucune différence)

Lea : Lea a déplacé la page Leapro-pro sys-dimensionnement-apache vers Dimensionnement d'un serveur web Apache

2023-12-04T20:33:15Z

Lea a déplacé la page Leapro-pro sys-dimensionnement-apache vers Dimensionnement d'un serveur web Apache

← Version précédente	Version du 4 décembre 2023 à 20:33
(Aucune différence)

Jiel : balises code

2012-05-20T12:11:46Z

balises code

← Version précédente		Version du 20 mai 2012 à 12:11
Ligne 59 :		Ligne 59 :

	La configuration, quasiment par défaut, contient :		La configuration, quasiment par défaut, contient :
	<code>		<div class="code">
	<IfModule prefork.c>		<IfModule prefork.c>
	# nombre maximum de processus au repos		# nombre maximum de processus au repos
Ligne 76 :		Ligne 76 :
	StartServers 5		StartServers 5
	</IfModule>		</IfModule>
	</~~code~~>		</div>
	Ce qui nous limite à 20 processus simultanés.		Ce qui nous limite à 20 processus simultanés.

Jiel le 27 avril 2011 à 15:00

2011-04-27T15:00:17Z

← Version précédente		Version du 27 avril 2011 à 15:00
Ligne 1 :		Ligne 1 :
	[[Catégorie:Services Web]]		[[Catégorie:Services Web]]
			[[Catégorie:Léa pour les pros]]

	== Dimensionnement d'un serveur web apache ==		== Dimensionnement d'un serveur web apache ==

Jiel le 27 avril 2011 à 13:50

2011-04-27T13:50:15Z

← Version précédente		Version du 27 avril 2011 à 13:50
Ligne 1 :		Ligne 1 :
			[[Catégorie:Services Web]]

	== Dimensionnement d'un serveur web apache ==		== Dimensionnement d'un serveur web apache ==
	~~---------------------------------------~~

	De nos jours, mettre en place un serveur web est une tache relativement facile.		De nos jours, mettre en place un serveur web est une tache relativement facile.
Ligne 167 :		Ligne 168 :
	Avec une limitation des clients, le serveur reste en place. Vous avez tout le loisir de modifier les pages, de rediriger les autres services ailleurs, ou de libérer la mémoire des taches non essentielles ( par exemple, basculer un serveur mysql ailleurs ).		Avec une limitation des clients, le serveur reste en place. Vous avez tout le loisir de modifier les pages, de rediriger les autres services ailleurs, ou de libérer la mémoire des taches non essentielles ( par exemple, basculer un serveur mysql ailleurs ).
	Et vous continuez à servir une partie des clients web.		Et vous continuez à servir une partie des clients web.

			<br/>
			<br/>
			'''<b>[[Reseau-index\|@ Retour à la rubrique Réseau et sécurité]]</b>'''
			<br/>

	{{Copy\|2006\|Michael Scherer\|CC-BY-SA}}		{{Copy\|2006\|Michael Scherer\|CC-BY-SA}}

195.220.252.125 : Correction orthographe et grammaire :)

2009-03-05T12:06:53Z

Correction orthographe et grammaire :)

Misc : ajout de MaxClient que j'ai oublié ( merci yanntech )

2006-12-05T21:35:05Z

ajout de MaxClient que j'ai oublié ( merci yanntech )

← Version précédente		Version du 5 décembre 2006 à 21:35
Ligne 128 :		Ligne 128 :

	<IfModule prefork.c>		<IfModule prefork.c>
			# 20 de base + les 40 plus haut
			# ce qui fait 60 clients
			MaxClient 60

	# nombre maximum de processus au repos		# nombre maximum de processus au repos
	# moitié de MaxClients, mais c'est plus au feeling		# moitié de MaxClients, mais c'est plus au feeling
Ligne 133 :		Ligne 137 :

	# nombre minimum de processus au repos		# nombre minimum de processus au repos

	MinSpareServers 5		MinSpareServers 5
	# nombre de requêtes avant de relancer le processus		# nombre de requêtes avant de relancer le processus
Ligne 140 :		Ligne 145 :
	StartServers 5		StartServers 5
	</IfModule>		</IfModule>


	== Pourquoi ne pas avoir pris la swap en compte dans le calcul ? ==		== Pourquoi ne pas avoir pris la swap en compte dans le calcul ? ==

Misc : Ajout de la doc

2006-11-02T12:46:12Z

Ajout de la doc

Nouvelle page

== Dimensionnement d'un serveur web apache ==
---------------------------------------

De nos jours, mettre en place un serveur web est une tache relativement facile.
La plupart des sites n'ayant pas pour vocation de remplacer yahoo et google, et
la capacité des machines étant en hausse constante, une installation de base de
apache suffit pour la plupart des particuliers.

Néanmoins, dans un contexte professionnel, ça ne suffit généralement pas.
Nous allons donc voir une méthode pour déterminer comment régler apache.
Ce guide ne prétend pas permettre de répondre à tout les problémes, mais peut
servir de base à des changements en finesse.

== Présentation de la machine et des besoins ==

Notre exemple est tiré d'un cas réel.
Le serveur en question tourne sur un noyau 2.6.16, avec un bi-xeon 2,8 Ghz,
1 Go de ram, et 2 Go de swap.
La version d'apache est une version 2.0.54.
Le serveur a une tache trés simple, c'est de servir de portail pour authentifier
les utilisateurs en dehors du réseau intranet. Chaque utilisateur se connecte, reçoit un
cookie, et surfe sur les pages du site.
Les utilisateurs sont dans une base ldap, les cookies dans une base postgresql, et le
portail est écrit en mod_python.
Pour diverses raisons, apache utilise le module prefork, sans thread, car les tests ont montré
des erreurs dûes au code non multithread du portail ( ou d'une bibliothèque associée ). Ça tombe bien, car cela simplifie le calcul de dimensionnement.

== Principes généraux sur l'optimisation d'apache ==

De nombreux documents existent sur le sujet, comme :
http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
http://www.jacobian.org/writing/2005/dec/12/django-performance-tips/
http://virtualthreads.blogspot.com/2006/01/tuning-apache-part-1.html

Je vous conseille de les lire en entier, et d'essayer de les comprendre.

Pour résumer, le principe général de l'optimisation est le suivant : pour chaque serveur, il
y a 4 ressources ( ou plus ) :
* la ram
* le disque
* le processeur
* la bande passante

Il faut identifier la ressource qui coincera la première, et si besoin, agir à ce niveau.
Dans le cas d'apache, ça dépend de ce qui est servi. Un site avec des pages complexes en php va utiliser du cpu, ou de la ram. Un site proposant des films ou des vidéos va surtout utiliser le disque ou la bande passante.

Dans le cas de notre exemple, le site n'utilise pas le disque, ne fait pas d'opération coûteuse en temps CPU, et n'est pas limité par le réseau.

Pour le savoir, c'est trés simple, il suffit d'utiliser ab ( apache benchmark ), et de surveiller
les ressources, avec htop, iostat, ntop, etc. Je vous conseille de lire cette article pour avoir une vue rapide des outils utilisés : http://www.redhat.com/magazine/011sep05/features/tools/
( ou le début de ce document http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf )

Dans notre exemple, la supervision des ressources vient de munin, et le benchmark d'un moteur de recherche interne mal réglé, poussant le serveur au delà des limites de la configuration par défaut.

Donc, après "benchmark", nous avons constaté que la limitation principal, ce fut le nombre de processus.

La configuration, quasiment par défaut, contient :
<code>
<IfModule prefork.c>
# nombre maximum de processus au repos
MaxSpareServers 10

# nombre minimum de processus au repos
MinSpareServers 5

# nombre maximum de processus
MaxClients 20

# nombre de requêtes avant de relancer le processus
MaxRequestsPerChild 1000

# nombre de serveurs lancés au démarrage
StartServers 5
</IfModule>
</code>
Ce qui nous limite à 20 processus simultanés.

Comme indiqué dans la documentation d'apache, c'est un protection. Permettre de lancer un nombre illimité de serveur ne sert à rien, car il y a toujours une ressource qui va manquer. Donc, cela permet de ménager la machine, pour intervenir en cas de probléme.

Néanmoins, ces valeurs ne sont pas optimales, et nous allons voir comment les augmenter, et de combien.

== Un peu de calcul ==

La mémoire, sous linux et sans doute sous d'autres unix, voir d'autres OS, est toujours occupé au maximum. Soit les processus qui tournent l'utilisent, soit le noyau se sert de ceci comme cache.

Notre première étape va donc être de calculer quel part est prise par le cache, via la commande free :

misc@teferi# free
total used free shared buffers cached
Mem: 1033980 978420 55560 0 83672 729744
-/+ buffers/cache: 165004 868976
Swap: 1999192 284 1998908

Soit, ~ 730 Mo de cache ( en dessous de cached ), sur un total de 1000 Mo. Parmi les 730 Mo, j'ai décidé d'en mettre la moitié pour apache, soit ~ 360 Mo. On peut en mettre plus, si le serveur ne fait que ça, mais je préfère laisser de la place pour d'autres taches, et 360 Mo seront largement suffisant, comme nous verrons par la suite.

La deuxiéme partie, c'est de savoir combien de serveur en plus peut on mettre dans 360 Mo. Le calcul est simple, on prends la mémoire prise par un serveur, et on divise.
Jusqu'ici, tout va bien, mais ça ne va pas durer.

La gestion de la mémoire sous linux est assez complexe. Les zones mémoires sont partagées entre les processus si elles sont identiques, les zones peuvent être en swap ou en mémoire, et d'une maniére général, les outils sont verbeux.

Pour déterminer la taille utilisée par un client, le premier pas est d'utiliser ps, pour voir les processus. C'est ainsi que j'ai vu que chaque serveur apache se connecte directement à postgresql, il faut donc déterminer la taille des 2 processus.

Je me suis basé sur ce guide ( http://www.kdedevelopers.org/node/1445 ), et j'ai obtenu les chiffres suivants grâce à 'top' :

Un processus apache prends en moyenne :
data(DATA) 7000, shared(SHR) 3500, resident(RES) 10000, virtual(VIRT) 16000

Un processus postgresql prends :
data(DATA) 1500, shared(SHR) 2800, resident(RES) 4000, virtual(VIRT) 17000

VIRT n'est pas utile dans notre calcul, c'est la mémoire demandé, pas la mémoire alloué.

SHR, c'est de la mémoire partagée. Comme nos processus sont identiques, c'est de la mémoire qui ne compte que pour le premier processus. Donc non utile pour notre calcul, ou du moins négligeable.

RES est la mémoire utilisée par le processus, mais ça compte aussi la mémoire qui est potentiellement partagée.

Il ne reste que DATA, obtenu via la touche 'f' dans top.
DATA, c'est la mémoire non partagée du processus, c'est donc ce qu'on cherche, dans notre cas.

Donc apache + postgresql, ça fait 9000 ko de DATA, soit à peu prés 9 mo par paire,
non partagés avec les processus déjà en mémoire.

Nous pouvons donc, sur les 360 Mo, mettre 360 / 9 = 40 paires en plus, donc 40 serveurs.

La configuration d'apache devient donc :

<IfModule prefork.c>
# nombre maximum de processus au repos
# moitié de MaxClients, mais c'est plus au feeling
MaxSpareServers 30

# nombre minimum de processus au repos
MinSpareServers 5
# nombre de requêtes avant de relancer le processus
MaxRequestsPerChild 1000

# nombre de serveurs lancés au démarrage
StartServers 5
</IfModule>

== Pourquoi ne pas avoir pris la swap en compte dans le calcul ? ==

En effet, il y a une partition de swap de 2 Go, et nous aurions pu la prendre
en compte. Mais j'estime qu'un serveur qui commence à utiliser la swap est un serveur
trop chargé. Utiliser la swap implique d'écrire sur le disque, ce qui est
plus lent, ce qui ralenti les lectures ( donc le lancement d'autres processus,
ou des données ), les écritures ( les logs ), et doit donc être évité en temps
normal.

De plus, il existe des serveurs utilisant le disque de façon bien plus intensive que apache,
et vous devez autant que possible séparer les ressources dans ce cas. Postfix et postgresql sont deux exemples de serveurs dépendants du disque, et il vaut mieux refuser une partie des clients en cas de pic, que de rendre la machine inutilisable.

Prenons un exemple :
vous avez, malgré ce document, décidé de mettre plus de clients qu'il est possible de faire tenir en mémoire. Et aujourd'hui, c'est la gloire, vous passez sur cnn, pour votre papier sur les camps de tortures illégaux au sud de la floride.

Vos premiers clients arrivent, puis, le serveur commence à placer des processus dans le swap. La charge continue de monter, et le serveur devient plus lent à répondre. Les clients s'accumulent, et les processus, mettant plus de temps à traiter les requêtes, sont de moins en moins nombreux à être disponible, et apache est donc obligé de mettre les requêtes dans une file.

Le serveur, croulant sous la charge, ne répond plus au ssh, ni à la majorité des requêtes, et vous ne pouvez pas vous connecter, afin de mettre une redirection, ou de placer le document autre part. Fin de la partie. Et bien sûr, tout les autres services de la machine en pâtissent.

Avec une limitation des clients, le serveur reste en place. Vous avez tout le loisir de modifier les pages, de rediriger les autres services ailleurs, ou de libérer la mémoire des taches non essentielles ( par exemple, basculer un serveur mysql ailleurs ).
Et vous continuez à servir une partie des clients web.

{{Copy|2006|Michael Scherer|CC-BY-SA}}

← Version précédente		Version du 5 mars 2009 à 12:06
Ligne 9 :		Ligne 9 :
	Néanmoins, dans un contexte professionnel, ça ne suffit généralement pas.		Néanmoins, dans un contexte professionnel, ça ne suffit généralement pas.
	Nous allons donc voir une méthode pour déterminer comment régler apache.		Nous allons donc voir une méthode pour déterminer comment régler apache.
	Ce guide ne prétend pas permettre de répondre à ~~tout~~ les problémes, mais peut		Ce guide ne prétend pas permettre de répondre à tous les problémes, mais peut
	servir de base à des changements en finesse.		servir de base à des changements en finesse.

Ligne 54 :		Ligne 54 :
	Dans notre exemple, la supervision des ressources vient de munin, et le benchmark d'un moteur de recherche interne mal réglé, poussant le serveur au delà des limites de la configuration par défaut.		Dans notre exemple, la supervision des ressources vient de munin, et le benchmark d'un moteur de recherche interne mal réglé, poussant le serveur au delà des limites de la configuration par défaut.

	Donc, après "benchmark", nous avons constaté que la limitation ~~principal~~, ce fut le nombre de processus.		Donc, après "benchmark", nous avons constaté que la limitation principale, ce fut le nombre de processus.

	La configuration, quasiment par défaut, contient :		La configuration, quasiment par défaut, contient :
Ligne 83 :		Ligne 83 :
	== Un peu de calcul ==		== Un peu de calcul ==

	La mémoire, sous linux et sans doute sous d'autres unix, voir d'autres OS, est toujours ~~occupé~~ au maximum. Soit les processus qui tournent l'utilisent, soit le noyau se sert de ceci comme cache.		La mémoire, sous linux et sans doute sous d'autres unix, voir d'autres OS, est toujours occupée au maximum. Soit les processus qui tournent l'utilisent, soit le noyau se sert de ceci comme cache.

	Notre première étape va donc être de calculer quel part est prise par le cache, via la commande free :		Notre première étape va donc être de calculer quel part est prise par le cache, via la commande free :
Ligne 94 :		Ligne 94 :


	Soit, ~ 730 Mo de cache ( en dessous de cached ), sur un total de 1000 Mo. Parmi les 730 Mo, j'ai décidé d'en mettre la moitié pour apache, soit ~ 360 Mo. On peut en mettre plus, si le serveur ne fait que ça, mais je préfère laisser de la place pour d'autres taches, et 360 Mo seront largement ~~suffisant~~, comme nous verrons par la suite.		Soit, ~ 730 Mo de cache ( en dessous de cached ), sur un total de 1000 Mo. Parmi les 730 Mo, j'ai décidé d'en mettre la moitié pour apache, soit ~ 360 Mo. On peut en mettre plus, si le serveur ne fait que ça, mais je préfère laisser de la place pour d'autres taches, et 360 Mo seront largement suffisants, comme nous verrons par la suite.

	La deuxiéme partie, c'est de savoir combien de serveur en plus peut on mettre dans 360 Mo. Le calcul est simple, on prends la mémoire prise par un serveur, et on divise.		La deuxiéme partie, c'est de savoir combien de serveur en plus peut on mettre dans 360 Mo. Le calcul est simple, on prends la mémoire prise par un serveur, et on divise.
Ligne 117 :		Ligne 117 :
	RES est la mémoire utilisée par le processus, mais ça compte aussi la mémoire qui est potentiellement partagée.		RES est la mémoire utilisée par le processus, mais ça compte aussi la mémoire qui est potentiellement partagée.

	Il ne reste que DATA, ~~obtenu~~ via la touche 'f' dans top.		Il ne reste que DATA, obtenue via la touche 'f' dans top.
	DATA, c'est la mémoire non partagée du processus, c'est donc ce qu'on cherche, dans notre cas.		DATA, c'est la mémoire non partagée du processus, c'est donc ce qu'on cherche, dans notre cas.

	Donc apache + postgresql, ça fait 9000 ko de DATA, soit à peu prés 9 mo par paire,		Donc apache + postgresql, ça fait 9000 ko de DATA, soit à peu prés 9 Mo par paire,
	non partagés avec les processus déjà en mémoire.		non partagés avec les processus déjà en mémoire.

Dimensionnement mémoire d'un serveur web Apache - Historique des versions

Lea : Lea a déplacé la page Dimensionnement d'un serveur web Apache vers Dimensionnement mémoire d'un serveur web Apache

Lea : Lea a déplacé la page Leapro-pro sys-dimensionnement-apache vers Dimensionnement d'un serveur web Apache

Jiel : balises code