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
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
Christophe
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.
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/
Le 19/09/2013 21:55, Bzzz a écrit :
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/
Christophe
Tu peux aussi augmenter le nombre de workers de nginx (Ã nb de cores
+ 1 max si mes souvenirs sont bons).
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é).
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/