Drupal et OVH :Fatal error: Allowed memory size of 33554432 bytes...

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by Altbzh on

Bonjour,
J'ai bien vu dans le forum que c'était un sujet qui avait été déjà abordé mais n'ai pu trouver de solution claire ...pour mon niveau de compétence !.
Je suis en hébergement mutualisé 90 et utilise Drupal. L'erreur est provoquée qd je lance certaines options administrateur (par ex "modules"). (commande qui tourne très bien en localhost avec 30 Mo et ss doute moins)
Un phpinfo ne me donne pas la taille permise de mon hébergement;
Les réponses que j'ai sur le forum OVH ne m'aident guère pr l'instant en remettant en question le choix Drupal. (" Drupal = usine à gaz".

Q1 : peut on régler la taille d'exécution des modules de son CMS ?
Q2 : comment ? (j'ai essayé vainement des memory_limit, ...)
Q3 : il doit bien y avoir une documentation ou un guide à OVH sur ce pb qui semble assez fréquent mais je n'ai pu le trouver ...
Q4 : qd on modifie des htaccess ou php.ini, faut-il redémarrer la base et si oui comment ?
Excusez ces questions de débutant et merci de vos futures réponses...

Forum : 
Support général
Version de Drupal : 
6.x

Soumis par davidm le 19 Mai, 2009 - 09:59

Rien à avoir avec OVH lui-même lorsque tu as ce type de message c'est que memory_limit dans ton php.ini n'est pas assez élevé (ça arrive vite avec Drupal si tu as quelques modules...).

Visiblement dans ton cas 32M ne suffit pas (dans mon cas, sur un gros site Drupal j'ai du monter au delà de 128M).... et je doute qu'un mutualisé soit suffisant pour avoir plus... ceci dit tu peux essayer...

Première solution c'est d'avoir accès à un php.ini personnalisé et spécifier :

memory_limit = 64M

En général sur les hébergements mutualisés, pas de php.ini accessible... sur OVH je ne crois pas que ce soit le cas (ça a pu changer depuis 4 ans moi je suis sur dédié).

Deuxième solution spécifier dans le fichier de config Drupal :

ini_set('memory_limit', '64M');

dans sites/default/settings.php

Troisième solution c'est de spécifier par exemple si tu veux 32 Még :

php_value memory_limit 64M

dans ton htaccess (mais en mutu, il faut que l'hébergeur l'autorise... toujours le même problème...).

Si tu ne peux pas monter au dessus de 32M, il va falloir songer à changer d'hébergeur soit pour un mutu qui donne plus de lattitude, soit pour un RPS (chez OVH ça reste pas trop cher : http://www.ovh.com/fr/produits/offres_rps.xml).

Drupal est un petit gourmand en mémoire...

Soumis par Altbzh le 19 Mai, 2009 - 11:22

Merci
Effectivement je ne pense pas à accuser OVH ...

Je ne vois pas de PhP.ini; j'ai essayé d'en créer un et cela n'a pas marché ...

J'ai essayé la troisième solution mais j'ai eu une erreur 500

La seconde solution, je l'ai testé ss résultat mais je me demandais si elle n'était pas à mettre ds le module qui créée l'erreur (
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 954394 bytes) in /homez.143/altbzh/www/drupal/includes/database.mysql-common.inc on line 41)
qd je fais Construction du site > modules.) et si je n'avais pas à faire une réinitialisation quelconque de la base et du serveur (logique)...

Sur OVH la valeur limite de la mémoire ne figure pas qd je fais un phpinfo alors que je l'ai en localhost ???

Bonne journée

Soumis par davidm le 19 Mai, 2009 - 12:53

Non un php.ini ne peut pas se "créer", c'est un fichier système auquel tu as accès ou non ;)

Tout ça veut dire que tu ne peux pas changer ta limite de mémoire est c'est compréhensible sur un mutualisé... Drupal est glouton côté mémoire (j'ai un site avec une centaine de modules qui bouffe 256M). Il faut un RPS ou un dédié pour des sites sérieux...

Soumis par Altbzh le 19 Mai, 2009 - 13:40

ok merci; mais mon site est tout petit plutôt genre maquette pr l'instant ! et il tourne avec 32 Mo en localhost ! je ne sais pas comment ils mutualisent sur Drupal : il doit y avoir un min et un max et un algo entre les deux ! mais je ne connais ni le min, ni le max !
je n'ai jamais examiné la solution RPS ni techniquement ni financièrement parlant !

à plus ! j'aurai sans doute d'autres questions plus tard sur Drupal au fur et à mesure de l'avancement de ma maquette...

Soumis par sushis le 19 Mai, 2009 - 16:14

Je viens d'avoir ce probléme et j'ai modifié le fichier php.ini comme dit au-dessus (merci davidm) et ça marche!

Si tu travaille sur Linux Ubuntu ou Debian, le fichier php.ini se trouve dans /etc/apache2/php.ini.

J'ai dû redémarrer mon serveur Web pour que les modifications soit pris en compte ( /etc/init.d/apache2 restart ).

En espérant t'avoir aider,

sushis

Soumis par Altbzh le 20 Mai, 2009 - 14:12

Bonjour,

En fait d'après le support OVH c'est un pb mémoire de la base de données !
message d'erreur : Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 954394 bytes) in /homez.143/altbzh/www/drupal/includes/database.mysql-common.inc on line 41"
ce qui correspond : j'ai 40 Mo de base, 7 d'utilisé; par contre je ne comprends pas comment ces 33 Mo sont utilisés par Drupal qd je fais "construction du site > modules ???

Soumis par sushis le 20 Mai, 2009 - 16:42

D'après le message d'erreur, il semble que c'est un problème "d'allocation de mémoire".

J'avoue ne pas savoir de quoi je parle!

Par contre, j'ai bien réussi à réglé le problème en modifiant le fichier php.ini... Mais sans savoir ce que signifie "la mémoire", c'est quoi la limite d'utilisation de mémoire vive du serveur pour le service web (apache2 dans mon cas)?

OVH c'est le nom de ton herbergeur?

Soumis par mchevallier le 29 Août, 2009 - 17:35

Salut,

Je réveil un post un peu vieu, mais rencontrant le même problème, autant tout concentrer tout au même endroit.

Je monte actuellement des sites pour des assoc, donc un peu lourd en modules, car les utilisateurs finaux comprennent déjà pas la différence entre un POP et un webmail, faut donc que Drupal travaille à leur place :-)

Je sature effectivement assez rapidement quand je veux aller sur admin/module.

Je viens de commander un petit sql privé à 128M RAM et 6€/mois.

Je vous tiendrai au courant du résultat.

A plus

Marc

Webmaster débutant... pour soi-même (si si) et quelques associations de son village :-)

Soumis par Altbzh le 29 Août, 2009 - 18:22

Bonjour,

par hasard : http://drupalfr.org/node/7663 ... pour OVH; à mon gd étonnement cela a marché ...j'ai qd mme une autre erreur qu'il doit y avoir moyen de réparer de la mme manière : max_allowed_packet ....
Tenez moi au courant ... Chez quel hébergeur votre petit sql privé ? petit inconvénient sf erreur de ma pert on ne peut pas en profiter pour créer des comptes mail ?
Bonne soirée

Alain

Soumis par mchevallier le 31 Août, 2009 - 08:34

Bon on parle d'OVH :) donc chez OVH le sql privé.

Effectivement, un Sql privé vient en complément de l'hébergement classique, pas en remplacement.

On ne peut d'ailleurs avoir un Sql privé qu'une fois qu'on a un hébergement.

Je viens de recevoir mes données de connexion, je fais des tests aujourd'hui et vous tiens au courant.

Quand au init_set proposé dans ton lien, j'avais testé avant de passer au sql privé.

Ca m'a aidé pour quelques modules, mais j'ai finit par dépasser à nouveau et j'ai comme l'impression que chez OVH en hébergé, 64M ne sert à rien, car le serveur bloque l'allocation à 32M. Mais c'est sans preuves.

A plus

Marc

Webmaster débutant... pour soi-même (si si) et quelques associations de son village :-)

Soumis par BlueWateR le 31 Août, 2009 - 10:46

Par contre le SQL privé tu n'as que 64 mo sur les 128 . Les 64 autres sont pour les systéme de fichiers , pour avoir une install plus réactive y parait .... .

Par-contre , j'ai discuté avec eux de ceux probléme . Et si tu veux et que tu as les compétences pour , tu peux prendre pour 2 euros de plus . Un RPS , comme çà , tu auras 1 cores et 512 mo ram (+ 512 mo de swap ) et 20 go de stockage en plus . Et là tu pourras choisir PostgreSQL 8.4 qui est bien plus performant que Mysql 5.1 .

Le probléme par rapport aux SQL privé , c'est que l'ip est public . Donc , il faudra gérer la sécurité et les attaques du serveur . L'accouplement du mutu et d'un RPS est possible .

Donne nous de tes nouvelles !

@plus

Soumis par Maxime69 le 1 Septembre, 2009 - 19:18

Je suis aussi preneur de l'information concernant les limites de SQL Privé car même problème avec l'erreur MySQL.

Où avez-vous eu l'information que sur les 128 Mo de RAM seuls 64 pouvez-être utilisés ? C'est un peu de honteux pour OVH d'arnaquer et de ne pas être transparent sur ce sujet si c'est le cas !

Soumis par s2x le 9 Février, 2010 - 19:01

bonjour,

je n'arrive pas à retrouver mon fichier php.ini pour en augmenter la mémoire.je suis certain d'avoir déjà vue ce fichier en faisant un autre site hébergé sur le même serveur .... j'ai un RPS chez ovh en attendant de pouvoir mettre en œuvre la première solution énoncée par davidm j'ai essayé les deux autres : avec la "solution 2" settings.php ça semble fonctionner un tout petit peu mieux et "pour ce qui est de la solution 2avec .htaccess" ça ne marche pas, cà me met un fatal error en grand.

Question subsidiaire: le site que je suis en train de faire est assez chargé en applications (et donc en modules installés) Y a-t-il une taille limite de mémoire à ne pas dépasser ou à partir de laquelle il faut songer à procéder autrement.

merci d'avance

Soumis par s2x le 9 Février, 2010 - 19:11

en fait en re-tripatouillant je me dis que ma question n'est peut être pas très pertinente

ajouter ini_set('memory_limit', '64M')dans mon fichier settings.php revient à modifier le fichier php.ini que je cherche en vain

ini = le fichier .ini que je cherche
set= le "setting" que je veux y placer

exacte?!

donc comme ça continuait à "ramer" je suis passé à 128M et çà à l'aire de fonctionner.