Fatal error: Allowed memory size of 33554432 bytes exhausted ?!? (Créer un compte)

  • Statut : non résolu
15 sujets de 1 à 15 (sur un total de 29)
  • Auteur
    Messages
  • #466727
    radiCarl
    Membre
    Chevalier WordPress
    137 contributions

    Bonjour,

    afin de pouvoir offrir une façon alternative de naviguer dans mon blogue, j’ai développé une page sur celui-ci qui devrait afficher les 100 derniers commentaires du blogue.

    Toutefois, depuis quelques jours, j’ai ce drôle de problème qui m’est apparut :

    Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 55946 bytes) in /home/radicar/public_html/wp-content/plugins/recent-comments-plugin/recent-comments.php on line 156

    Alors, si quelqu’un sait de quoi il en retourne ici, j’apprécierais beaucoup de connaître la nature de ce problème (et sa solution 😉

    Merci

    #658976
    BertrandB21
    Participant
    Maître WordPress
    590 contributions

    Et bien c’est un débordement de la mémoire alloué par l’hébergeur.
    Certains hébergeur acceptent de revoir le memory limit … d’autre pas
    Il y a peut être un moyen de limiter l’utilisation de mémoire par wordpress mais là je ne sais pas

    Je ne sais pas bien qu’elle est le rôle du paramètre WP_MEMORY_LIMIT qui est fixé par défaut à 32M
    Essayer de rajouter 10M en rajoutant
    define(‘WP_MEMORY_LIMIT’,’42M’); dans wp_config.php
    Mais l’hébergement n’est pas obligé d’honorer la demande

    #658977
    radiCarl
    Membre
    Chevalier WordPress
    137 contributions

    Merci Bertrand… mais l’astuce ne fonctionne pas… je vais donc écrire à mon hébergeur.

    Merci encore pour la piste

    #658978
    Anonyme 2
    Participant
    Maître WordPress
    10589 contributions

    Bonjour,

    il est gentil d’indiquer quelques infos,le nom de l’hébergeur,la version de WordPress que vous utilisez,plugins utilisés,thème.
    Merci d’avance

    #658979
    Fabino
    Participant
    Chevalier WordPress
    106 contributions

    Bonjour Carl,

    Je ne sais pas si ça peut t’intéresser : j’ai fait aussi ce genre de page sur mon blog en utilisant le plugin Wp-RecentComments. Ce qui donne ça : http://www.jobalternative.net/accueil/commentaires/

    L’avantage c’est de présenter un extrait (nbre de mots paramétrable), de reprendre l’avatar et d’avoir un menu de navigation qui permet de paginer tous les commentaires.

    #658980
    alain61
    Participant
    Initié WordPress
    2 contributions

    Bonjour,

    Idem pour moi au moment de la mise à jour de 2.8.3 en 2.8.4 … dommage ! :fire:

    Ca se passe chez ovh

    Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2608509 bytes) in ……. www/wp-includes/http.php on line 1327

    #658981
    SmartiesKiller
    Membre
    Chevalier WordPress
    109 contributions

    idem sur phpnux depuis le passage a la 2.8.4 j’ai le droit a cette erreur dans le bo pour les extrension,les resumé etc etc

    #658982
    legheer
    Membre
    Initié WordPress
    12 contributions

    je ne puis pas passer à la version 2.8.4 ni telecharger de nouvelles images dans flashfader depuis que je me fais héberger chez Network-Hosting.com.
    Je croyais avoir trouvé une alternative à e3b.org après son plantage, et la déception de la lenteur de phpnux.
    Bof… faudra chercher autre chose.

    #658984
    low-R
    Membre
    Initié WordPress
    11 contributions

    Même soucis chez ovh pour la mise à jour 2.8.5 :(

    Edit : Avec l’astuce à Bertrand ça marche !!! Merci 😆

    #658985
    piekes
    Membre
    Maître WordPress
    725 contributions

    Hello

    Pour commencer, il ne s’agit pas vraiment d’un problème lié à WP, mais à PHP en général. Tous les CMS basés sur ce langage ont peu ou prou les mêmes problèmes. Augmenter la quantité de mémoire allouée aux scripts est certes une bonne chose, mais ne fait qu’espacer les incidents. Et dans le pire des cas, c’est le serveur Apache qui fini par planter après deux ou trois épisodes de ce genre.

    En désespoir de cause, après de longues bagarres avec l’optimisation d’Apache / PHP / WP, nous avons dans ma boîte fini par jeter l’éponge. Et admis que “ça plante” de temps à autre.

    Donc un script pour relancer Apache et mySQL tous les jours à 4 heures du matin. Et un autre pour vérifier toutes les cinq minutes si les susdits Apache et mySQL tournent, et les relancer dans le cas contraire. Fin des soucis.

    Évidemment, cette approche n’est pas pensable dans un contexte d’hébergement mutualisé…

    #658986
    BertrandB21
    Participant
    Maître WordPress
    590 contributions
    piekes wrote:
    En désespoir de cause, après de longues bagarres avec l’optimisation d’Apache / PHP / WP, nous avons dans ma boîte fini par jeter l’éponge. Et admis que “ça plante” de temps à autre.

    j’en déduirais que vous êtes en mod_php en fastcgi le plantage de php ne doit pas poser de pb à Apache

    #658987
    piekes
    Membre
    Maître WordPress
    725 contributions
    BertrandB21 wrote:
    j’en déduirais que vous êtes en mod_php en fastcgi le plantage de php ne doit pas poser de pb à Apache

    C’est effectivement le choix de notre responsable système… Et celui qui est fait, si je ne m’abuse, sur la très grosse majorité des serveurs.

    #658988
    BertrandB21
    Participant
    Maître WordPress
    590 contributions

    su mon hébergement 1and1 c’est du CGI
    sur un hébergement nfrance c’est du fastcgi
    sur mon hébergement ovh c’est du CGI

    donc la très grosse majorité ben euh … déjà tout ceux qui proposent deux versions de php ce n’est pas le cas

    Après un choix est un choix et il peut se baser sur d’autres contraintes.

    #658989
    piekes
    Membre
    Maître WordPress
    725 contributions
    BertrandB21 wrote:
    su mon hébergement 1and1 c’est du CGI
    sur un hébergement nfrance c’est du fastcgi
    sur mon hébergement ovh c’est du CGI

    donc la très grosse majorité ben euh … déjà tout ceux qui proposent deux versions de php ce n’est pas le cas

    Après un choix est un choix et il peut se baser sur d’autres contraintes.

    Je n’ai pas la moindre expérience des hébergeurs… Toujours bossé dans des boîtes qui ont leurs propres serveurs dans leurs locaux. Toujours en mod_php. Et notre ingénieur qui me confirme que les essais de passage en mode CGI faits par le passé n’ont apporté qu’une baisse sensible des performances (-25% avec fastCGI) en moyenne, sans amélioration sensible de la stabilité.

    #658990
    thalasso
    Membre
    Chevalier WordPress
    495 contributions

    Le problème d’Apache est qu’il conserve la mémoire allouée maximum pour un même thread. Donc si un script PHP a besoin de 40 Mo pour fonctionner à un moment T et que les paramètres d’Apache font qu’un même thread est utilisé pour 150 enfants, ces 40 Mo seront gardés pour les 150 enfants, même s’ils n’ont besoin chacun que de 1 Mo en réalité. Maintenant, si ce même serveur exécute 50 scripts PHP ayant besoin de 40 Mo chacun sur 50 threads, même à des moments différents, Apache leur consacrera, au total, 50 x 40 Mo = 2.000 Mo.

    De mon côté, sur mon serveur disposant de 12 Go, mais découpé en VM de 512 Mo de RAM + 1.024 Mo de swap, j’ai la configuration Apache suivante, coté threads & co :

    # prefork MPM
    # StartServers: number of server processes to start
    # MinSpareServers: minimum number of server processes which are kept spare
    # MaxSpareServers: maximum number of server processes which are kept spare
    # MaxClients: maximum number of server processes allowed to start
    # MaxRequestsPerChild: maximum number of requests a server process serves 
    
        StartServers          5
        MinSpareServers       5
        MaxSpareServers      10
        MaxClients           50
        MaxRequestsPerChild  25
    
    
    # worker MPM
    # StartServers: initial number of server processes to start
    # MaxClients: maximum number of simultaneous client connections
    # MinSpareThreads: minimum number of worker threads which are kept spare
    # MaxSpareThreads: maximum number of worker threads which are kept spare
    # ThreadsPerChild: constant number of worker threads in each server process
    # MaxRequestsPerChild: maximum number of requests a server process serves
    
        StartServers          5
        MaxClients           50
        MinSpareThreads       5
        MaxSpareThreads      10
        ThreadsPerChild      25
        MaxRequestsPerChild  25

    avec, côté PHP :

    memory_limit = 28M

    Cela dit, pour réduire la mémoire utilisée par WordPress, il est généralement bon de désactiver tous les plugins non indispensables. En effet, la mémoire est généralement très mal gérée par ceux-ci.

15 sujets de 1 à 15 (sur un total de 29)
  • Vous devez être connecté pour répondre à ce sujet.