Voilà depuis un petit moment, wordpress fait planter mon serveur en consommant toute la mémoire (500Mb), nécessitant de stopper et de relancer le serveur apache (pour libérer la mémoire). Personnellement je n’ai aucune idée de la cause de cette surconsommation de mémoire, je suis donc à la recherche de conseil pour identifier le problème lié à wordpress.
J’utilise un paquet de plugins dont les principaux sont présentés sur cette page, de plus le blog est “caché” grace au plugin wp-cache qui doit normalement limiter la sollicitation de la base mysql. Le phpinfo du serveur est ici.
Qui a une idée? Merci pour votre aide…
38 Comments
Je serais assez intéressé par la réponse, car j’ai le même problème avec mon blog ! Même s’il est plus petit que 2803, il pompe tout, et fais beaucoup planté le serveur !
Tu peux compiler php avec –enable-memory-limit qui permet ensuite de limiter la consommation de mémoire par script php. Ca peut être utile.
J’aurais tendance à dire qu’il faut libérer de la mémoire et augmenter le swap (donc jouer avec les partitions, donc pas évident). Entre un serveur qui rame et un serveur qui plante, je crois que le choix est vite fait, non ?
Le fichier “php.ini” (placé quelque part sur ton serveur en fonction de la configuration de celui-ci) contient la configuration relative à la mémoire maximale qu’un script peut exploiter. Elle est généralement définie à 8 Mo par défaut. Tu peux y changer aussi le temps maximum d’exécution d’un script (généralement 30 secondes maximum par défaut). Cependant, il n’y a pas de raison de toucher à ces paramètre si les scripts s’exécutent correctement, ce qui semble être le cas sur ce serveur. En effet, le souci que semble rencontrer est lié surcharge liée au trafic et non à l’exécution d’un script particulier).
Dans le cas où j’avais rencontré un problème similaire, j’avais opté pour une réduction de la quantité de connexions MySQL simultannées (fichier de configuration MySQL “my.cnf”) à 40 et la réduction du timeout pour forcer la fermeture des connexion ouvertes mais anormelement oubliées ouvertes. Sachant qu’une page de ton blog nécessite généralement moins de 5 secondes pour être entièrement chargée, 40 connexions simultannées à MySQL permettraient alors 8 pages vues par seconde. C’est très largement suffisant sur ton blog, je devine !
Un autre paramètre intéressant du côté de MySQL (”my.cnf”) vient du cache. Parfois, il n’est pas actif par défaut, ou bien sa taille est sous-dimensionnée. Sur mon serveur, je l’ai mis à 25 Mo (voir “query_cache_size”). Ceci a pour avantage d’améliorer la réactivité du serveur de BDD et de réduire le temps de chargement des pages, et ainsi augmenter le nombre moyen de pages par seconde pouvant être servies. Cela dit, avec un plug-in de cache WP, cela ne devrait pas avoir un impact important, je devine. Mais dans ce cas, le nombre de connexions MySQL concurrentes peut éventuellement être réduit, chacune consommant un peu de mémoire (du genre, quelques Mo).
Du côté d’Apache, c’est au fichier “httpd.conf” qu’il faut s’attaquer. Tout comme pour MySQL, chacun instance possible consomme de la mémoire, et le maximum d’instances concurrentes dépasse souvent la capacité mémoire du serveur. Personnellement, j’ai modifié le paramètre “Timeout” à 180 secondes maximum (contre 300 par défaut sur mon serveur). Inutile de laisser de trainer des instances d’Apache inutiles en mémoire. Dans le même genre, j’ai réduit “KeepAliveTimeout” à 10 (contre 15 par défaut chez moi). Eventuellement, tu peux réduire le nombre de threads/clients/etc. (en fonction de la configuration de ton serveur) pour limiter le nombre d’instances d’Apache simultannément en mémoire, là encore.
Mais bon, je ne suis pas assez calé pour aller plus loin dans l’optimisation du serveur ou encore dans le détail…
J’y pense : certains robots explorateurs du web ont la fâcheuse tendance d’aspirer assez sauvegement les sites. Du coup, il est bon de leur présenter un fichier robots.txt qui les empêche de venir (s’ils le respectent), voire de bloquer leurs IP (via iptables ou un .htaccess). En effet, l’immense majorité de ces robots ne propose aucune contrepartie au site ainsi aspiré (aucun visiteur envoyé depuis un moteur associé, notamment).
Il faut voir plein de parametre
Si le maxclient n’a pas etait atteind ca peut etre ca aussi…
Si le MaxRequestsPerChild est à 0 (si tu est en mode treaded) c’est a cause de ca mais le à 100 pour tester ca …
Cordialement
Kimkof
thanks, je vais voir cela avec mon hébergeur car reste à toucher un peu tout cela maintenant.
Est ce que vous utiliser le mysql.query.cache? moi je n’en sais rien il faut que je trouve la ligne de commande pour le savoir…
Si tu dois rebooter apache pour que 2803 refonctionne cela vient que de apache et non de mysql…
regarde dans ton .htaccess et augmente ton allocation mémoire en rajoutant
php_value memory_limit 128M
(128 M pour exemple choisi la taille que tu veux)
Sylvain dans le .htaccess tu veux que je regarde quoi?
merci je vais tester cela
Tu as essayé de désactiver le plugin wp-cache juste pour voir si c’est lui qui prend toute cette mémoire?
bonjour
je me rappellle quand j’avais mon dédié, j’avais un pb au niveau de la quantité de log, j’avais du faire un cron pour le vider plus régulièrement ou un truc comme ca.
ca remonte un peu
Guillaume je viens de regarder d’un peu plus près wp-cache et je viens de mettre en place la compression gzip des fichiers http://markjaquith.wordpress.c.....-and-gzip/ cela ne peut pas faire de mal déjà.
Voir l’évolution ici : http://www.port80software.com/.....Submit1=go
Henri, la compression gzip tu peux l’activer directement dans Apache, pas besoin de toucher à quoi que ce soit dans le plugin wp-cache.
http://httpd.apache.org/docs/2.....flate.html
D’ailleurs j’ai l’impression que c’est déjà fait sur ton serveur Apache, tes pages sont bien toutes encodées gzip quand on regarde dans les headers.
Tu sollicites encore plus le plugin wp-cache en plus je pense, et la compression gz ca n’a rien à voir avec l’occupation mémoire d’Apache, ca accélère juste le transfert des pages du serveur vers le navigateur.
Essaye de désactiver wp-cache juste pour voir.
ok je désactive… Pour Gzip je ne pense pas qu’il soit actif sur le serveur d’ailleurs
ton hebergeur n’aurait pas fait une mise à jour du système ? (OS, Apache, etc …)
Non je ne pense pas cela merde depuis longtemps mais je veux solutionner ce problème car cela me prend la tête…
Guillaume, wp-cache est hors de cause puisque la mémoire a été entièrement consommée alors que wp-cache était désactivé… (je viens de le remettre en marche d’ailleurs).
L’investigation continue
Dans ton apache2.conf
tu as quoi comme valeur à ca
StartServers 15
MinSpareServers 5
MaxSpareServers 10
MaxClients 250
MaxRequestsPerChild 0
???
Envoie moi par mail ou ici
Cordialement
Thomas
Thomas, je fais comment (ligne de commande ssh) pour avoir accès au apache2.conf?
merci
En fait ca depent de ta distribution
Pour debian : vi /etc/apache/apache2.conf
Pour les autres distribution ca depents comment ca ete compilé mais ca doit etre sensiblement pareils
ça serait plus sumple avec le rapport de crash ?
Spami> je n’ai pas de rapport de crash, c’est simplement qu’il n’y a plus de mémoire disponible donc çà plante tout. Je viens de changer le paramètre MaxRequestsPerChild pour le passer de 0 à 100 cela devrait donc limiter la casse normalement (dixit kimkof). Wait and see donc…
tu dois biena voir un log des erreurs, il y en a toujours sous apache.
genre: “[Sat Feb 18 23:44:16 2006] [error] PHP Warning: main(comun/connexion.inc.php): failed to open stream: No such file or directory in c:\\program files\\easyphp1-8\\www\\dailymotion_copy\\admin\\\\ban.php on line 2″
Tu touve la date du plantage, tu lis et tu connais la raison
dans le genre :
[Sun Mar 11 09:13:31 2007] [error] could not make child process 31885 exit, attempting to continue anyway
J’en ai 50 comme cela…
C’est que tu a des personne qui veule voir ton site mais apache ne peut cree d’autre processus possible que ce soit du fait que le maxrequestperchild etait à 0
Est ce que tu as ca aussi qui train dans les logs henri? error.log
[error] server reached MaxClients setting, consider raising the MaxClients setting
non j’ai bcp de chose mais pas cela
C’est une bonne chose
cat /var/log/syslog | grep apache2 ( peut indique des chose en cas de plantage de apache aussi)
Sinon avec la chose que je t’ai fait changer ta déja du reboot apache?
non cela n’a pas été rebooté depuis… on verra demain.
Zut je viens de le rebooter! Donc problème tjs d’actualité.
D’apres ce que j’ai vu quand le site marché pas
Apache fonctionné mais le serveur sql non
Donc c’est plus un plantage de mysql
Peut-être des pistes à étudier ici : http://www.wordpress-fr.net/20.....as-si-sur/
Je crois plutot que le probleme est lié a un module Wordpress. Le meilleur test est de les désactiver un a un et voir comment le site se comporte sans les modules en question.
J’essaye ce soir le coup des plugins en déactivant le plus exotiques on verra bien, je sais déjà que cela n’est pas wp-cache
Heu… c’est moi où elle est faite avec les pieds la config de ton serveur ?! Ya pas mal de petites choses qui mériteraient d’être réajustées. C’est le genre d’indices qui me fait dire que tu devrais peut-être solliciter les connaissance d’un pote admin à toi (dont c’est le métier ou la passion) pour qu’il affine ta config afin d’éviter les risque de type piratage, perte de mémoire, boucle infinie, etc.
Bref, ce n’est que mon avis de dev, j’suis pas admin réseau ^^
Note que WP-Cache n’est intéressant que si tu as un trafic qui le justifie. En effet, la création du cache correspondant aux données prend plus de temps que la création d’une simple page sans cache. En revanche, ce sont les accès suivants qui sont gagnés par le cache. Bref, l’intérêt du cache n’est intéressant que si les accès suivant la création du cache sont suffisamment nombreux pour justifier le travail supplémentaire à la création du cache. Je lisais récemment qu’en matière de WP-Cache, celui-ci n’était intéressant qu’à partir de 2.000 visites par jour. Cela dit, je devine que tu les obtiens allègrement !
Essaye aussi de réduire la valeur de KeepAliveTimeout.
Par défaut, tu dois être à KeepAliveTimeout 15
Passes-le à 3. Si ton site a beaucoup de demandes simultanées, ca peut aider.
Tu peux meme essayer de le désactiver complétement pendant 1 jour ou 2 pour voir (KeepAlive On à passer sur Off).
Est-ce que quand tu es planté, c’est permanent, ou est-ce que le systeme redevient stable au bout d’un moment (si tu n’interviens pas à temps par exemple ?)
Je veux bien creuser plus longuement avec toi si tu veux et étudier tes logs, passes moi un mail si besoin.
Bon courage.
Merci tornad, a priori c’est un plugin qui pose problème, celui qui génère le sitemap pour google… Je fais chercher une solution de remplacement!