Eu mudei do Drupal 7.14 para 7.15 há três semanas e, portanto, estou encontrando uma série de erros de limite de memória muito sofisticados (para mim) . Esses erros ocorrem sempre que estou tentando limpar o cache no desempenho ou executar scripts de atualização.

Minha empresa de hospedagem aumentou meu limite de memória no php.ini para 126 M, 256 M, 512 M e até 1024 M. Mas os erros ainda ocorrem. Migrei meu site do VPS compartilhado, mas o erro ainda ocorre incrivelmente. Não tenho como nem faço ideia de como seguir em frente.

Aqui estão os erros:

• Erro fatal: tamanho de memória permitido de 536870912 bytes esgotado (tentou alocar 30 bytes) em /home/example/public_html/sites/all/modules/views/views.module na linha 416

• Erro fatal: tamanho de memória permitido de 536870912 bytes esgotado (tentou alocar 108 bytes) em /home/example/public_html/includes/menu.inc na linha 2736

• Erro fatal: tamanho de memória permitido de 536870912 bytes esgotado (tentou alocar 71 bytes) em /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module na linha 59

• aloque 64 bytes) em /home/example/public_html/sites/all/modules/views/includes/base.inc na linha 93

Eu também bati minha cabeça contra uma parede nos últimos tempos com problemas de memória do Drupal. Aqui está o meu conhecimento coletado sobre o tópico:

1. As visualizações (podem) usam muita memória

Eu amo algumas visualizações (e Panels, CTools e tudo que o merlinofchaos toca com seus dedos poderosos e poderosos), mas é possível criar configurações com vários relacionamentos que usam muita memória. Se você desativar suas Views e o problema de memória desaparecer, é provável que uma View mal construída esteja causando o problema.

O que fazer se for um View e você realmente precisar desse View para funcionar? Tente inseri-lo em código (via exportador em massa ou recursos; veja abaixo. Eu codifiquei manualmente a funcionalidade do tipo Views para melhorar o desempenho com muito pouco sucesso) para começar. Outro pensamento é refazer a Visualização de uma maneira diferente - se, no final das contas, você está obtendo termos de taxonomia, verifique se o tipo de Visualização é uma Visualização de Taxonomia ao criá-la; não crie uma Visualização de conteúdo que use relacionamentos para obter os termos de taxonomia.

Também vale a pena mencionar aqui que o Panels também supostamente usa muita memória - eu realmente não a comparei, então não posso confirmar isso.

2. Mover coisas do banco de dados para o código é uma prática muito boa

Levei vários sites do Drupal para perceber isso, mas manter tudo o que foi criado por meio de uma interface do usuário no banco de dados (especialmente as configurações de Views e Panels) é uma prática recomendada do Drupal. Por quê? Aumenta a carga no banco de dados e não pode ser controlado por versão. O primeiro ponto é particularmente problemático em termos de uso de memória - em vez de apenas carregar o conteúdo do banco de dados do View, o site também deve carregar os componentes do view. Isso é exacerbado pela maneira como o Drupal usa tabelas: abstraindo tudo até o enésimo grau, cada parte da funcionalidade do Drupal usa uma nova tabela, resultando em algumas solicitações que juntam vários bilhões de tabelas. Isso cria hérnias para as pessoas da ciência da computação (ressalva: o link é bobo), mas não pode ser evitado com um software tão modular e fácil de usar quanto o Drupal.

A solução? Use o Exportador em Massa (Incluído no CTools) ou Recursos para empacotar bits de código que atualmente residem no banco de dados como código do módulo.

3. Temas também podem comer memória

Seu tema possui muitos arquivos de modelo (ou seja, arquivos no nome / modelo / /)? Nesse caso, a memória é consumida cada vez que um desses arquivos é carregado. Se você estiver criando modelos especificamente para impedir a exibição de bits do Drupal, tente:

1. Alterar permissões para que esse bit não apareça para funções específicas de usuário não administrador.
2. Usando CSS para ocultar elementos.

A primeira opção é obviamente o que você quer fazer para coisas que afetam a segurança - você não deseja usar CSS para ocultar um botão "editar" para determinados usuários, apenas para que eles os ocultem por meio do Firebug ou o que seja.

4. Não exagere nos módulos contrib

Embora algumas vezes um site precise de muitos módulos de contribuição, não exagere. Cada módulo ativado (nota: ativado. Os módulos desativados não usam nenhuma memória) usam memória. Isso é um pouco óbvio, mas vale a pena notar, independentemente.

5. O VPS é (às vezes) uma mentira

Na minha experiência, algumas empresas de hospedagem sem escrúpulos adoram tentar enviar sites do Drupal para servidores VPS - são mais caras e liberam espaço de hospedagem compartilhado para cada vez mais sites WordPress. A situação é agravada pelo fato de os webhosts frequentemente não anunciarem (ou mesmo lhe informarem, se solicitado) qual é o limite superior de memória para hospedagem compartilhada.

Infelizmente, se um site não está sob tráfego intenso e ainda está travando, o problema provavelmente tem mais a ver com a configuração do Drupal do que qualquer outra coisa. Empurrar um usuário para o VPS apenas atrapalha as águas e adiciona mais variáveis ​​para lidar (é a configuração do servidor da web? Configuração do PHP? Configuração do VPS? Configuração do convidado do VPS? Configuração do host VPS, mesmo?).

6. Quando tudo mais falhar, clone no host local e bata com um stick

Essa é uma grande razão pela qual as pessoas usam a metodologia dev-staging-production com controle de versão - quando tudo mais falha, você pode fazer um despejo de banco de dados, git clonar o site em um servidor de teste local e depois atrapalhar o site no site. testando o servidor sem se preocupar em quebrar algo no servidor de produção.

Para problemas de memória, isso geralmente significa desativar os módulos um por um até que o causador do problema seja exposto. Também pode apontar problemas relacionados ao host da web - se o site funcionar perfeitamente em uma instalação local com memória configurada para algo razoável como 128 MB, você saberá que o seu host está em crack.

tl; dr

Meu instinto é que é chain_menu_access que está causando o problema. Tente desativar isso e limpar o cache, veja se funciona.

Também adicionarei a essa resposta enquanto penso em outras coisas para tentar ...

Você pode tentar colocar o profiler do PHP como o XHProf ou o profiler embutido do Xdebug para inspecionar o que está acontecendo na solicitação.

Views é um porco da memória. O cache do Drupal pode ajudar. O Drupal carrega apenas os módulos ativos, no entanto, se eles criarem tabelas ou tiverem outros objetos, eles poderão ficar por aqui. Somente a desinstalação removerá a maioria dos artefatos. Usamos a autorização / permissão do drupal e escrevemos nossos próprios módulos. Não é o melhor, mas o desempenho é muito melhor e mais fácil de ajustar. Também fazemos o mesmo para o WP.

No meu caso, o problema do limite de memória foi gerado pelo sistema de cache (módulos Boost e Boost Expire). Isso me deu um problema para atualizar o módulo ou as visualizações. Uma vez desativado, os módulos Boost funcionam bem.