Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian Soucis de consommation de RAM Apache2/php5 (squeeze)

Soucis de consommation de RAM Apache2/php5 (squeeze)

3 réponses
Avatar
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
Signaler un problème avec ce contenu

3 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Bzzz
On Thu, 19 Sep 2013 21:41:48 +0200
Christophe wrote:

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/
Avatar
Christophe
Bonjour,

Le 19/09/2013 21:55, Bzzz a écrit :
On Thu, 19 Sep 2013 21:41:48 +0200
Christophe wrote:

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/
Avatar
Bzzz
On Sat, 21 Sep 2013 13:09:38 +0200
Christophe wrote:

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/