Conseil configuration Apache

[Robinson]

Bonjour,

J'ai un site internet qui gère un nombre assez important d'images générées via php. Ces images sont toutes simples.
Cependant chaque image étant un fichier php, cela crée de nombreux processus apache qui ralentissent le serveur aux heures de pointes.
Quelle configuration est la plus adaptée ?

Actuellement :

Code: Tout sélectionner

Timeout 300
KeepAlive On
MaxKeepAliveRequests 150

KeepAliveTimeout 5

<IfModule mpm_prefork_module>
    StartServers         10
    MinSpareServers      10
    MaxSpareServers     140
    MaxClients          256
    MaxRequestsPerChild 4000
</IfModule>

<IfModule mpm_worker_module>
    StartServers         1O
    MaxClients          256
    MinSpareThreads      40
    MaxSpareThreads     160
    ThreadsPerChild      35
    MaxRequestsPerChild 4000
</IfModule>

Mon serveur est puissant (Bi-Xeon Quad 8x2.33, 16Go ram).

Merci.

[Julia41]

Timeout, je mettrais ça à 2/3s : si une image mets plus que ce temps là à être affichée par l'utilisateur, c'est "pas normal" (sauf grosse image bien sûr.
Pour les autres conf, j'augmenterais un peu le MinSpare.

Je trouve le MaxRequests.. un peu élevé.

Tu peux gagner un peu en virant pas mal de module inutile.

Autre question qui est plus "bête" qu'autre chose, mets-tu en cache tes images ? (à moins qu'elles doivent vraiment changer souvent).
Au niveau du serveur web, tu pourrais tester lighttpd.

[Robinson]

Merci.
J'ai fais quelques modifs mais cela n'apporte rien pour le moment.

Je vais donc essayer de réduire le nombre d'images générées par php même si ça s'annonce galère :p

[jcaron]

Quant tu dis que le serveur ralentit aux heures de pointe, qu'est-ce-qui sature? Le CPU (0% idle, load average élevé), ou la RAM (la machine commence à swapper)?

Dans le premier cas, la config Apache ne va pas changer grand chose, il faut soit plus de CPU dispo (i.e. une machine avec plus de cores), soit en utiliser moins. La première chose à faire c'est, si possible, de mettre en place un cache afin de ne pas avoir à regénérer les images à chaque fois. Tu peux aussi t'assurer que ton script gère bien les Expires et autres headers de contrôle de cache qui vont avec, et même les If-Modified-Since, tout ça pouvant réduire le nombre de requêtes à traiter.

Dans le deuxième cas, ça peut paraître contre-intuitif, mais il faut souvent réduire le nombre de processus Apache (MaxClients). Un processus Apache avec php peut bouffer beaucoup beaucoup de RAM (ça dépend de la façon dont php est installé et configuré, mais voir un processus qui fait >100 Mo est loin d'être choquant). Dans ta config, tu indiques que tu peux avoir 256 processus, à raison de 100 Mo par processus ça fait plus de 25 Go, donc ta machine qui n'en a que 16 (moins l'espace occupé par le système, les autres processus...) va swapper, et là ça va vraiment ramer. Il faut que tu détermines la taille maximale d'un de tes processus (en examinant ps -axl), et tu mets MaxClients à (par exemple 14 Go / taille max). Suivant la config, MaxKeepAliveRequests et MaxRequetsperChild peuvent avoir une influence aussi.

Au final, c'est souvent une conbinaison des deux problèmes: tu satures le CPU, dont Apache utilise plus de processus pour essayer de traiter les requêtes, tu satures la RAM, tu swappes, badaboum.

La première chose est donc avant tout d'avoir plus d'éléments sur ce qui se passe quand ça rame (un top et un ps -axl à ce moment-là seraient un bon début).

Jacques.

[Robinson]

Aucun soucis CPU et RAM...

idle souvent autour de 90% (le load average à 0,80)
RAM, 250mo libre et 13Go dans le cache, aucun swap.

Tasks: 437 total, 1 running, 436 sleeping, 0 stopped, 0 zombie

C'est continuellement ainsi.
ça doit bouchonner quelque part mais j'ai du mal à déceler où.

[jcaron]

Et c'est comme ça même quand ça rame? Ca se manifeste comment exactement, le fait que ça rame? C'est valable pour toutes les requêtes ou seulement certaines? http uniquement ou aussi ssh par exemple? Tu as des requêtes SQL? Le serveur SQL est-il sur la même machine? Sinon, n'est-ce-pas cette machine-là qui rame?

Autre possibilité, n'y a-t-il pas saturation au niveau des accès disque? Là je ne sais pas trop comment ça se mesure sous les différentes variantes de Linux (sous FreeBSD cf systat -io, gstat...).

Autre piste, une saturation du lien Ethernet, ou une limitation de la bande passante utilisable? Des pertes de paquets?

Sinon tu as peut-être un problème de locking quelque part qui fait que tu ne peux pas faire deux requêtes simultanément?

Que donne le server-status d'apache?

Jacques.

[Robinson]

Oui c'est ainsi quand ça rame.
Je n'ai qu'un seul serveur, mysql ne pose pas de soucis apparent.

C'est bien http qui pose soucis. Ce matin quand cela "ramait", mêmes de simples images mettaient un peu de temps à s'afficher, mais principalement c'est toute la page qui était en attente, dès qu'elle se "débloquait", elle apparaissait relativement vite.

J'ai diminué de moitié les images générées via php, cela va un peu mieux, moins de processus simultanés mais toujours des lags trop importants.
J'avais déjà constaté ces lags depuis quelques temps avant de mettre en place ces images. Elles ont amplifié le problème visiblement.

Ce qui est bizarre, c'est que les lags arrivent assez brutalement, à 400 connectés simultanés, pas de soucis, très bonne vitesse; à 420, ça commence à laguer en s'amplifiant plus le nombre augmente.

La commande server-status est introuvable.

[jcaron]

Les "connectés simultanés" c'est toujours un concept particulièrement intéressant dans le cadre d'un serveur web. Si tu parles de nombre de connectés tels que comptés un CMS quelconque (genre nombre d'utilisateurs qui ont fait une connexion dans les X dernières minutes), ce n'est normalement pas spécialement important. Si tu parles du nombre de connexions TCP simultanées c'est un autre problème.

Server-status c'est un module de Apache (mod_status), qu'il faut généralement activer et paramétrer dans httpd.conf (http://httpd.apache.org/docs/2.2/mod/mod_status.html). Ca te permet ensuite de voir combien de slots sont utilisés.

Une autre piste c'est que tes processus fassent appel à des ressources externes qui prennent un peu de temps à répondre (pas forcément beaucoup, mais assez pour que ça bloque un processus qui attend une réponse pendant quelques dizaines/centaines de millisecondes par exemple). Dans ce cas le nombre de slots (MaxClients) va être saturé par ces processus en attente, et les requêtes qui arrivent derrière doivent attendre qu'un slot se libère. Dans ce cas il faut augmenter MaxClients, en tenant compte de la RAM utilisée par chaque processus et de ta RAM totale, sinon tu vas swapper (cf post précédent).

Jacques.

[Robinson]

Bonjour et merci.

Etrangement ce matin, la taille des processus apache a diminué de moitié (10mo) et la mémoire RAM libre est en constante augmentation, là elle est à 4,3Go.
Comment cela se fait-il qu'elle sorte du cache ainsi ?

Cependant, le site continue de laguer dès que le nombre de connectés augmente, avec des pages apparaissant seulement entre 1 et 2,5 secondes après un clic... Elles s'affichent rapidement, mais il y a une attente avant leur déclenchement.

Le load average est par contre repassé au-dessus de 1, mais toujours avec un idle autour de 90%...

[jcaron]

Quand les processus atteignent MaxRequestsPerChild, ils s'arrêtent, et un nouveau est lancé à la place, qui sera plus petit, et va ensuite grossir au fur et à mesure qu'il traite des requêtes. Assez souvent (surtout si le nombre de processus reste à peu près constant, en général à l'une des deux limites), tous les processus redémarrent à peu près en même temps.

Tes processus Apache ne font que 10-20 Mo? Php est configuré comment? Module, externe, fastcgi...?

Grosso-modo load-average = (1-idle) * nombre de cores (tant que idle > 0). Donc 90% idle, 8 cores, load average = +- 0.8. Tant que ton load average reste inférieur à 8 normalement il reste du idle, et tout va bien de ce point de vue.

Tu n'as pas répondu concernant le fait que tes scripts fassent éventuellement appel à une ressource externe (une requête http par exemple) et ce que dit server-status...

Jacques.

[Robinson]

Concernant MaxRequestsPerChild, je l'avais diminué à 1000 d'où certainement la diminution d'utilisation RAM.

Oui les processus apache font 10mo (20 hier).
Php est configuré en externe.

Oki, merci j'ai compris pour le idle

Et non aucun script ne fait appel à une requête externe (hormis les scripts audiotel mais pas de soucis de ce côté).
Pour server-status, je n'arrive pas à l'activer.
Je l'active bien dans apache2.conf mais la commande est toujours inconnue, et l'exécution de mondomaine.com/server-status ne fonctionne pas non plus (pas d'autorisation).
Je me souviens avoir déjà voulu l'installer/activer mais sans succès.

[jcaron]

Il faut que mod_status soit chargé et activé, bien sûr. Et de mémoire la config par défaut inclut une limitation qui ne permet de le consulter qu'en local ou un truc du genre, donc il faut évidemment adapter à ton cas particulier. Une fois activé tu peux aussi y accéder via apachectl fullstatus.

Jacques.

[Robinson]

J'ai enfin réussi...
Voici ce que cela donne :

Server Version: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with
Suhosin-Patch

Server Built: Jul 14 2009 20:44:04
__________________________________________________________________

Current Time: Monday, 15-Feb-2010 14:44:10 CET
Restart Time: Monday, 15-Feb-2010 14:38:37 CET
Parent Server Generation: 49
Server uptime: 5 minutes 32 seconds
221 requests currently being processed, 35 idle workers

CKKKKCCKK_CKKKKKCK_KKKC_KCKKKCKWC_KKCK_KCC_KKCKKKCKKKC__CKCCKKK_
KKC_KKKCW_KRKKKC_KKKCCCC_KKKKK_KKKKKCCKKKCCKKK_KKKKKCCKCKKKKKKCK
KKKCKKKCKKCKKKCCKCKCKKK_CK__KWCKCCKKCKCW_KKKKCKKKC_K_KCCCK_KKKK_
KKK_K_CKCCKWC_CC_CKKKWWKC_C__KKKKKCKKCCKKK_CKKKK_KK_CK_KCCKKK_CC
................................................................
................................................................
................

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Mais actuellement, cela ne rame pas, moins de visiteurs.

[jcaron]

Ben regarde ce que ça donne au moment où ça "rame", tu vas probablement observer qu'il n'y a pas de "_" (idle workers) et probablement pas ou peu de "." (open slot).

En fait ton problème vient des keep-alives: le serveur garde la connexion (et le processus) au cas où il y aurait une autre requête du même client (pour éviter d'établir une nouvelle connexion TCP à chaque fois), et ça sature le nombre de processus disponibles (pour tout de plein de processus qui ne font en fait rien), et quand ça arrive les nouvelles connexions doivent attendre qu'un slot se libère (par timeout du keepalive). Deux options:
- augmenter sensiblement MaxClients (en faisant attention à ne pas faire swapper la machine pour autant, i.e. en tenant compte de la taille de chaque process Apache + la taille du process php qui peut aller avec)
- réduire KeepAliveTimeout. Ce qui compte surtout ce sont les requêtes "enchaînées" (genre page + css + js + images) donc 2-3 secondes doivent probablement suffire.

Evidemment si tu as un cas particulier genre ton site fait une requête toutes les secondes pour mettre à jour je ne sais quoi, tu te retrouves en gros avec un processus par utilisateur présent, et il faut donc augmenter MaxClients en conséquence (ou carrément désactiver les KeepAlives, mais ça a d'autres conséquences sur les performances).

Jacques.

[Robinson]

Merci pour toutes ces infos

KeepAliveTimeout a déjà été passé à 3.

Je vais augmenter Maxclients. Autrefois, il était plus élevé. Depuis un changement de serveur, je ne l'avais pas rehaussé.
Je le passe à 350.
Ce soir, je ferai un point sur ce que ça donne.