Recherche conseils techniques

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…

Publié le mars 9, 2007 par . Cette article a été publié dans wordpress et taggé , , , . Enregistrer le lien de l'article.

38 commentaires sur “Recherche conseils techniques”

  1. 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 !

  2. 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.

  3. 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…

  4. 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).

  5. 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

  6. 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…

  7. Si tu dois rebooter apache pour que 2803 refonctionne cela vient que de apache et non de mysql…

  8. 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)

  11. Tu as essayé de désactiver le plugin wp-cache juste pour voir si c’est lui qui prend toute cette mémoire?

  12. 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

  14. 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.

  18. 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

  19. 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

  21. 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

  23. 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…

  24. 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 :-)

  25. 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…

  26. 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

  28. 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?

Les commentaires sont fermés.