[Résolu] => Solution pour régler Memory Limit liste des modules

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.

J'ai eu du mal à trouver une solution alors pour que d'autres ne se prennent pas le choux pendant 10 ans voici une réponse claire.

Si vous rencontrez un message Allowed..blabalb...memory limit pour connexion..., saisissez la ligne suivante :

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

Le valeur de 64M peut être modifiée.

Où ça ? Ici :

Dans le fichier modules.inc situé dans le répertoire includes

En exemple ça donne ça (peut être différent en fonction de votre configuration) :

<?php
// $Id: module.inc,v 1.115.2.1 2009/02/16 10:32:10 goba Exp $
ini_set('memory_limit', '64M');
/**
* @file
* API for loading and interacting with Drupal modules.
*/

P.S : Je suis chez OVH en hébergement 90Plan

Version de Drupal : 

Ce genre de lignes a plus sa place ds le fichier setting.php car sinon ta modif va etre effacee a la prochaine mise a jour de drupal.

Par contre ca m'intrigue que ce changement ait un effet car generalement c pas vraiment une valeur que les hebergeur laisse modifier ?

Salut,

Ce genre de ligne a sans doute plus sa place dans le fichier setting.php je te le confirme mais cela n'a aucun effet parfois. J'en suis la preuve vivante.

Cet hébergeur permet de forcer pour l'exécution d'un script cette configuration du memory_limit, c'est la raison pour laquelle je la met en avant.

Pour l'intrigue en effet, mais voilà une des raisons qui permet peut être de choisir un hébergeur au lieu d'un autre. Ce que je n'ai pas essayé, c'est de monter plus haut...

A+

Si j'ai bien compris le message :
ça plante parce que 1 662 941 bits ont été requis sur un total possible de 67 108 864 bits.

Totalement incohérent !

Faut-il migrer sur serveur sql non-mutu ?
Quel type chez OVH ?

Si j’ai bien compris le message : ça plante parce que 1 662 941 bits ont été requis sur un total possible de 67 108 864 bits.

1.6Mb en plus sur les 67Mb. Totalement coherent.

Attention, ça ne veut pas dire que ton script va prendre 67+1.6, ca peut prendre plus. Ca plante juste des que ça dépasse les 67Mb (a peu pres)

Il y a quelques minutes, je suis passé sur un SQL privé d'OVH avec 128Mo mémoire.
Rien n'a changé : toujours le même message.
Est-ce la bdd qui est corrompue ?
J'ai 203 tables ! Y compris celle des modules désinstallés. Pas un peu dépensier, Drupal ?

Merci Haza pour l'attention que tu portes à mon souci.

OVH m'a informé que ma base spécialement dédiée à ce seul site (même pas en multi-site) avait atteint 49Mo / 50Mo. 20 inscrits seulement. > 6000 attendus dans 10 jours. Donc, ne pas stéterniser sur des solutions SQL inadaptées.
=> J'ai migré sur SQL privé qui est illimité en taille de base et en nombre de connexions.

Faut-il quand même modifier les settings de la mémoire php ?
Jusqu'à présent, cela a planté à chaque tentative d'allocation forcée.

Tout ce que je dis, c'est que les erreurs du type

Fatal error : Allowed memory size of 67108864 bytes exhausted (tried to allocate 1662941 bytes)…

sont lié a apache/php, et pas du tout a MySQL. Mettre un serveur SQL de bourrin ne résoudra rien a ceci. (meme si ton dans cas c'est nécessaire car tu avais atteint la limite -ridicule- de OVH)

Ne pas pouvoir changer la memory_limit sur un mutu, ca ne me choque pas. Ce sont des serveurs mutualisé par nature, si tous le monde s'amuse a modifier cette valeur, le serveur va très vite tomber, et entraîner des centaines d'autre clients avec lui.

1 ou 5 millions, ca ne change presque rien.

Plus tu installes de module, plus tu va consommer de mémoire. Tout en sachant que certain module consomme beaucoup plus que d'autre, et qu'on est jamais a l'abris d'erreurs de programmation (même dans les modules qu'on trouve sur drupal.org) qui ferait monter en flèche la consommation de mémoire.