В последнее время я также бьюсь головой о стену из-за проблем с памятью в Drupal. Вот мои собранные знания по теме:
1. Представления (могут) использовать много памяти
Мне нравятся некоторые виды (и панели, и CTools, и все, что merlinofchaos касается своими могучими, могучими пальцами), но возможно создать конфигурации с несколькими взаимосвязями, которые используют много памяти. Если вы отключите ваши представления и проблема с памятью исчезнет, скорее всего, это неправильно сконструированное представление, вызывающее проблему.
Что делать, если это View, и вам действительно нужен этот View для работы? Попробуйте для начала поместить его в код (с помощью Bulk Exporter или Features; см. Ниже. У меня есть функциональность, подобная представлениям вручную, чтобы повысить производительность при очень небольшом успехе). Другая мысль состоит в том, чтобы переделать представление другим способом - если в конечном итоге вы получаете термины таксономии, убедитесь, что тип представления является представлением таксономии при его создании; не создавайте представление контента, которое использует отношения, чтобы получить термины таксономии.
Также стоит упомянуть, что Panels также предположительно использует много памяти - я не проверял это, поэтому не могу подтвердить это.
2. Перенос содержимого из базы данных в код - очень хорошая практика
Мне потребовалось несколько сайтов на Drupal, чтобы понять это, но хранить все, что было создано с помощью пользовательского интерфейса в базе данных (особенно конфигурации Views и Panels), является худшей практикой на Drupal. Почему? Это увеличивает нагрузку на базу данных и не может контролироваться версиями. Первый пункт особенно проблематичен с точки зрения использования памяти - вместо простой загрузки содержимого из представления из базы данных сайт также должен загружать сами компоненты представления. Это усугубляется тем, как Drupal использует таблицы: абстрагируя все до n-й степени, каждый бит функциональности Drupal использует новую таблицу, в результате чего некоторые запросы объединяются в таблицы bajillion. Это вызывает у гинекологов грыжи (предостережение: ссылка глупа), но этого нельзя избежать с помощью такого программного модуля, который был бы модульным и удобным для пользователя, как Drupal.
Решение? Используйте Bulk Exporter (входит в комплект CTools) или функции, чтобы упаковать биты кода, в настоящее время находящиеся в базе данных, в виде кода модуля.
3. Темы могут также съесть память
Много ли в вашей теме файлов шаблонов (т. Е. Файлов в themename / templates /)? Если это так, память используется каждый раз, когда один из этих файлов загружается. Если вы создаете шаблоны специально для подавления отображения битов Drupal, попробуйте либо:
- Изменение разрешений, чтобы бит не отображался для определенных ролей пользователя без прав администратора.
- Использование CSS для скрытия элементов.
Очевидно, что первый выбор - это то, что вы хотите сделать для вещей, влияющих на безопасность - вы не хотите использовать CSS, чтобы скрыть кнопку «редактировать» для определенных пользователей, только чтобы они затем отображались с помощью Firebug или чего-либо еще.
4. Не отказывайтесь от дополнительных модулей
Хотя иногда сайту нужно много модулей для вклада, не переусердствуйте. Каждый включенный (примечание: включен. Отключенные модули не используют память) модуль использует память. Это немного очевидно, но стоит отметить в любом случае.
5. VPS (иногда) ложь
По моему опыту, некоторые недобросовестные хостинговые компании любят пытаться перенести сайты Drupal на VPS-серверы - они дороже и освобождают пространство общего хостинга для еще большего количества сайтов WordPress. Ситуация усугубляется тем фактом, что веб-хосты часто не рекламируют (или даже не охотно сообщают вам, если их спросят), какой верхний предел памяти используется для виртуального хостинга.
Увы, часто, если сайт не перегружен и все еще падает, проблема, скорее всего, связана с конфигурацией Drupal, чем с чем-либо еще. Выталкивание пользователя в VPS просто мутит воду и добавляет больше переменных для работы (это конфигурация веб-сервера? Конфигурация PHP? Гостевая конфигурация VPS? Даже конфигурация хоста VPS?).
6. Когда все остальное терпит неудачу, клонируйте к localhost и бейте его палкой
Это главная причина, по которой люди используют методологию dev-staging-production с контролем версий - когда все остальное терпит неудачу, вы можете сделать дамп БД, выполнить клонирование сайта на локальный тестовый сервер и затем по-королевски испортить сайт на сервере. тестирование сервера, не беспокоясь о том, чтобы что-то сломать на рабочем сервере
Что касается проблем с памятью, это обычно означает отключение модулей один за другим, пока не будет выявлен тот, который вызывает проблему. Это также может указывать на проблемы, связанные с веб-хостингом - если сайт отлично работает при локальной установке с объемом памяти, установленным на что-то разумное, например 128 МБ, то вы знаете, что ваш веб-хост работает без ошибок.
ТЛ; др
Моя интуиция в том, что проблема заключается в chain_menu_access. Попробуйте отключить это и очистить кеш, посмотрите, работает ли он.
Я также добавлю к этому ответу, как я думаю о других вещах, чтобы попробовать ...