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:
- Alterar permissões para que esse bit não apareça para funções específicas de usuário não administrador.
- 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 ...