Je suis passé de Drupal 7.14 à 7.15 il y a trois semaines et, par conséquent, je rencontre une série d' erreurs de limite de mémoire très sophistiquées (pour moi) . Ces erreurs se produisent chaque fois que j'essaie d'effacer le cache des performances ou d'exécuter des scripts de mise à jour.

Ma société d'hébergement a augmenté ma limite de mémoire dans php.ini jusqu'à 126 M, 256 M, 512 M et même 1024 M. Mais les erreurs se produisent toujours. J'ai migré mon site de partagé à VPS, mais l'erreur se produit toujours incroyablement. Je n'ai aucun moyen et aucune idée de comment avancer.

Voici les erreurs:

• Erreur fatale: taille de mémoire autorisée de 536870912 octets épuisée (tentative d'allocation de 30 octets) dans /home/example/public_html/sites/all/modules/views/views.module à la ligne 416

• Erreur fatale: taille de mémoire autorisée de 536870912 octets épuisée (tentative d'allocation de 108 octets) dans /home/example/public_html/includes/menu.inc sur la ligne 2736

• Erreur fatale: taille de mémoire autorisée de 536870912 octets épuisée (tentative d'allocation de 71 octets) dans /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module à la ligne 59

• allouer 64 octets) dans /home/example/public_html/sites/all/modules/views/includes/base.inc sur la ligne 93

J'ai également frappé ma tête contre un mur la dernière fois avec des problèmes de mémoire Drupal. Voici mes connaissances recueillies sur le sujet:

1. Les vues (peuvent) utiliser beaucoup de mémoire

Je m'aime quelques vues (et Panels et CTools et tout ce que merlinofchaos touche avec ses doigts puissants et puissants), mais il est possible de créer des configurations avec des relations multiples qui utilisent beaucoup de mémoire. Si vous désactivez vos vues et que le problème de mémoire disparaît, c'est probablement une vue mal construite qui cause le problème.

Que faire s'il s'agit d'une vue et que vous avez vraiment besoin de cette vue pour fonctionner? Essayez de le mettre en code (via un exportateur en bloc ou des fonctionnalités; voir ci-dessous. J'ai une fonctionnalité similaire à celle des vues codée à la main afin d'améliorer les performances avec très peu de succès) pour commencer. Une autre pensée est de refaire la vue d'une manière différente - si finalement vous en êtes aux termes de taxonomie, assurez-vous que le type de vue est une vue de taxonomie lors de sa création; ne créez pas une vue de contenu qui utilise des relations pour obtenir des termes de taxonomie.

Il pourrait également être utile de mentionner ici que Panels utilise également soi-disant beaucoup de mémoire - je ne l'ai pas vraiment évalué, donc je ne peux pas le confirmer.

2. Le déplacement de trucs de la base de données dans le code est une très bonne pratique

Il m'a fallu plusieurs sites Drupal pour le réaliser, mais conserver tout ce qui est créé via une interface utilisateur dans la base de données (configurations Vues et Panneaux en particulier) est une pire pratique Drupal. Pourquoi? Il augmente la charge sur la base de données et ne peut pas être contrôlé par la version. Le premier point est particulièrement problématique en termes d'utilisation de la mémoire - au lieu de simplement charger le contenu de la vue depuis la base de données, le site doit également charger les composants de la vue lui-même. Ceci est exacerbé par la façon dont Drupal utilise les tables: en résumant tout au nième degré, chaque bit de la fonctionnalité de Drupal utilise une nouvelle table, ce qui entraîne certaines demandes joignant un bajillion de tables. Cela donne des hernies aux informaticiens (mise en garde: le lien est idiot), mais ne peut pas vraiment être évité avec un logiciel aussi modulaire et convivial que Drupal.

La solution? Utilisez Bulk Exporter (inclus avec CTools) ou Features pour empaqueter des bits de code résidant actuellement dans la base de données en tant que code de module.

3. Les thèmes peuvent aussi manger de la mémoire

Votre thème contient-il beaucoup de fichiers modèles (c'est-à-dire des fichiers dans le nom / modèles /)? Si tel est le cas, la mémoire est consommée à chaque fois qu'un de ces fichiers est chargé. Si vous créez des modèles spécifiquement pour empêcher l'affichage de bits de Drupal, essayez soit:

1. Modification des autorisations afin que le bit n'apparaisse pas pour des rôles d'utilisateur non administrateur spécifiques.
2. Utiliser CSS pour masquer des éléments.

Le premier choix est évidemment ce que vous voulez faire pour les choses affectant la sécurité - vous ne voulez pas utiliser CSS pour masquer un bouton "éditer" pour certains utilisateurs, seulement pour les avoir puis les afficher via Firebug ou autre.

4. N'allez pas trop loin sur les modules contrib

Alors que parfois un site a besoin de beaucoup de modules de contribution, n'allez pas trop loin. Chaque module activé (remarque: activé. Les modules désactivés n'utilisent aucune mémoire) utilise un module de mémoire. C'est un peu évident, mais mérite d'être noté malgré tout.

5. Le VPS est (parfois) un mensonge

D'après mon expérience, certaines sociétés d'hébergement sans scrupules aiment essayer de pousser des sites Drupal vers des serveurs VPS - ils sont plus chers et cela libère de l'espace d'hébergement partagé pour de plus en plus de sites WordPress. La situation est aggravée par le fait que les hébergeurs n'annoncent souvent pas (ou ne vous disent même pas volontiers si demandé) quelle est la limite de mémoire supérieure pour l'hébergement partagé.

Hélas, souvent si un site n'est pas sous un trafic intense et continue de planter, le problème a probablement plus à voir avec la configuration de Drupal qu'autre chose. Pousser un utilisateur vers VPS brouille simplement les eaux et ajoute plus de variables à gérer (Est-ce la configuration du serveur Web? La configuration PHP? La configuration invité VPS? La configuration hôte VPS, même?).

6. Lorsque tout le reste échoue, clonez vers localhost et battez-le avec un bâton

C'est une grande raison pour laquelle les gens utilisent la méthodologie de développement de production avec contrôle de version - lorsque tout le reste échoue, vous pouvez effectuer un vidage de base de données, git cloner le site sur un serveur de test local, puis gâcher royalement le site sur le tester le serveur sans se soucier de casser quoi que ce soit sur le serveur de production.

Pour les problèmes de mémoire, cela signifie généralement désactiver les modules un par un jusqu'à ce que celui à l'origine du problème soit exposé. Il peut également pointer vers des problèmes liés à l'hébergeur - si le site fonctionne parfaitement sur une installation locale avec une mémoire définie à quelque chose de raisonnable comme 128 Mo, alors vous savez que votre hébergeur est en panne.

tl; dr

Mon instinct est que c'est chain_menu_access qui cause le problème. Essayez de désactiver cela et de vider le cache, voyez si cela fonctionne.

J'ajouterai également à cette réponse en pensant à d'autres choses à essayer ...

Vous pouvez essayer de mettre un profileur PHP comme XHProf ou le profileur intégré de Xdebug pour inspecter ce qui se passe dans la demande.

Views est un porc de mémoire. La mise en cache de Drupal peut vous aider. Drupal ne charge les modules actifs que s'ils créent des tables ou ont d'autres objets qui peuvent traîner. Seule la désinstallation supprimera la plupart des artefacts. Nous utilisons les autorisations / autorisations de drupal et écrivons nos propres modules à l'intérieur. Pas le meilleur mais les performances sont bien meilleures et plus faciles à régler. Nous faisons de même pour WP.

Dans mon cas, le problème de limite de mémoire a été généré par le système de cache (modules Boost et Boost Expire). Cela me donne un problème pour mettre à jour le module ou les vues. Une fois désactivés, les modules Boost fonctionnent correctement.