Soucis de consommation de RAM Apache2/php5 (squeeze)

Le
Christophe
Bonjour à tous,

Dans notre parc de clients actifs à la boite, nous en avons encore un
certain nombre en Debian Lenny avec apache2 libapache2-mod-php5 php5 +
quelques modules (mysql, ldap, curl, tous d'origine paquet debian) .
Aucun soucis à signaler sur ces derniers, si ce n'est l'ancienneté de la
distribution.

D'autres sont en squeeze , avec les mêmes modules installés (en version
plus récente du coup) , et la même appli PHP en même version qui tourne
dessus.

Nous constatons une consommation mémoire énorme des processus apache au
bout d'un "certain temps" lorsque le serveur est en Squeeze
contrairement à la Lenny. (et pour avoir fait la comparaison de tous les
serveurs Squeeze comparés à tous les serveurs Lenny, la différence est
flagrante 10% sur les lenny , et plus de 80% sur les squeeze).

Sur des petits clients , ca ne pose pas de soucis (bien que cela soit
inquiétant), en revanche , pour de plus gros, la swap est attaquée, et
très largement, ce qui donne lieu, a des timeouts sur tout ce qui est
hébergé par le serveur, avant qu'apache ne soit killé par 'oom-killer'
et que tout revienne à la normale :( .

Tout ce qui était "deprecated" en PHP 5.3 a été corrigé sur l'appli. Les
logs, font état de notice sur quelques index de tableaux non trouvés ,
mais ni plus ni moins que ce qui tourne sur les Lenny.

Une des corrections apportée a été de modifier le niveau de log de PHP
pour ne pas prendre en compte les notice. Il y a du mieux , mais on
recule pour mieux sauter : ca monte moins vite, et au final, on arrive ,
tôt ou tard à la même situation.

Nous avons d'autre part des VM sous Proxmox (Squeeze également) qui
hébergent des sites sous Wordpress (rien à voir avec la précedente
application, mais avec la même configuration), et régulièrement, nous
devons redémarrer la machine pour les mêmes raisons.

Tous les serveurs ne sont pas au même niveau de mise à jour, mais pour
autant le symptôme est le même pour tous les serveurs Squeeze.

Malgré parcours en détail des logs au moment du problème, nous sommes
particulièrement désarmés, car rien d'inhabituel n'y est constaté.

Avez vous déjà constaté ce comportement lors du passage de Lenny à
Squeeze ?

Nous avons pensé à changer de solution pour soit du CGI/FastCGI, soit du
php5-fpm (potentiellement coupé à NGINX) , mais cela nécessite un
travail assez conséquent de validation. Et dans l'état des choses , nous
souhaiterions éviter.

Auriez vous des solutions alternatives à proposer ?

Christophe.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/523B537C.7040507@stuxnet.org
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bzzz
Le #25673232
On Thu, 19 Sep 2013 21:41:48 +0200
Christophe
Nous avons pensé à changer de solution pour soit du CGI/FastCGI,
soit du php5-fpm (potentiellement coupé à NGINX) , mais cela
nécessite un travail assez conséquent de validation. Et dans
l'état des choses , nous souhaiterions éviter.



C'est pourtant l'une des solts la plus fiable; cependant, la
conso excessive de RAM peut aussi venir d'un défaut du kernel
et un test de charge entre les 2 solts possibles serait
intéressant et parlant.

Auriez vous des solutions alternatives à proposer ?



Pas vraiment; personnellement, j'ai cessé d'utiliser apache quand
j'ai testé nginx (passage +130MB à… 2MB, même avec u ne charge
importante, pour le daemon svr http).
La conf nginx nécessitera sûrement des tweaks, mais une fois
validée, c'est start & oubli :)

--
Drinks: Mais nan mec j'étais pas bourré...
Krazy: y a une vidéo qui tourne, t'étais entrain de
CHANTER ALLONGE SUR LA ROUTE
Drinks: ...
Drinks: Je chantais bien?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Christophe
Le #25675942
Bonjour,

Le 19/09/2013 21:55, Bzzz a écrit :
On Thu, 19 Sep 2013 21:41:48 +0200
Christophe
Nous avons pensé à changer de solution pour soit du CGI/FastCGI,
soit du php5-fpm (potentiellement coupé à NGINX) , mais cela
nécessite un travail assez conséquent de validation. Et dans
l'état des choses , nous souhaiterions éviter.



C'est pourtant l'une des solts la plus fiable; cependant, la
conso excessive de RAM peut aussi venir d'un défaut du kernel
et un test de charge entre les 2 solts possibles serait
intéressant et parlant.

Auriez vous des solutions alternatives à proposer ?



Pas vraiment; personnellement, j'ai cessé d'utiliser apache quand
j'ai testé nginx (passage +130MB à… 2MB, même avec une charge
importante, pour le daemon svr http).
La conf nginx nécessitera sûrement des tweaks, mais une fois
validée, c'est start & oubli :)




On a commencé à mettre en place en test. PHP5-FPM d'un côté / NGINX et
Apache (FastCGI pour les deux) de l'autre.

le serveur Web ne consomme effectivement plus rien. NGINX semble
effectivement mieux s'en sortir, mais la différence avec Apache n'a pas
été flagrante dans cette configuration lors des tests.

Gros point d'honneur à NGINX sur la facilité de conf, et les
possibilités que cela laisse entrevoir ;) .

On a fait quelques tests de montée en charge. C'est PHP5-FPM qui en
prend plein sa face (c'est d'une certaine logique ;) ). Et une fois que
la charge retombe, ca libère bien la mémoire. (J'ai un peu de mal à
comprendre comment il gère ca du reste).

On a pas encore fini les tests. et il y a surement encore quelques
variables de conf à modifier pour optimiser tout ca. Mais le
comportement, de prime abord, me parait tout de même plus sain.

@+
Christophe.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #25675932
On Sat, 21 Sep 2013 13:09:38 +0200
Christophe
On a fait quelques tests de montée en charge. C'est PHP5-FPM qui
en prend plein sa face (c'est d'une certaine logique ;) ). Et une



Tu peux aussi augmenter le nombre de workers de nginx (à nb de cores
+ 1 max si mes souvenirs sont bons).

fois que la charge retombe, ca libère bien la mémoire. (J'ai un
peu de mal à comprendre comment il gère ca du reste).



Il fork à chaque fois et les enfants meurent lorsque la charge
redescend - si la charge est susceptible de bcp varier, il
peut être intéressant de laisser vivre un certain nombre d'enfants
en RAM; c'est réglable dans /etc/php5/fpm/pool.d/www.conf (ou le nom
que tu lui as donné).

On a pas encore fini les tests. et il y a surement encore quelques
variables de conf à modifier pour optimiser tout ca. Mais le
comportement, de prime abord, me parait tout de même plus sain.



Si tu as des interrogations sur certains aspects de conf, le forum
nginx répond assez bien et très correctement.

--
[D]: je suis libre jeudi après-midi et vendredi après-midi
après 14h pour passer l'entretien.
[S]: Très bien. Jeudi-après midi 10h c’est possible ?
[D]: Vous avez vraiment un doctorat?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme