- Statut : non résolu
- Ce sujet contient 28 réponses, 16 participants et a été mis à jour pour la dernière fois par
, le il y a 12 années et 2 mois.
-
Messages
-
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
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 pasJe 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 demandeMerci Bertrand… mais l’astuce ne fonctionne pas… je vais donc écrire à mon hébergeur.
Merci encore pour la piste
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’avanceBonjour 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.
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
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
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.Même soucis chez ovh pour la mise à jour 2.8.5
Edit : Avec l’astuce à Bertrand ça marche !!! Merci 😆
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é…
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
BertrandB21 wrote:j’en déduirais que vous êtes en mod_php en fastcgi le plantage de php ne doit pas poser de pb à ApacheC’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.
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 CGIdonc 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.
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 CGIdonc 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é.
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 :
avec, côté PHP :
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.
- Vous devez être connecté pour répondre à ce sujet.