Збільшення межі пам’яті не допомагає у фатальній помилці: Дозволений розмір пам’яті… / модулі / представлення / view.module на лінії 416


11

Три тижні тому я перейшов з Drupal 7.14 на 7.15, і тому я стикаюся з серією дуже складних (для мене) помилок обмеження пам'яті . Ці помилки виникають у будь-який час, коли я намагаюся очистити кеш-пам'ять у виконанні або запустити сценарії оновлення.

Моя хостингова компанія збільшила ліміт пам’яті в php.ini до 126 М, 256 М, 512 М і навіть 1024 М. Але помилки все ж трапляються. Я перемістив свій веб-сайт із спільного доступу до VPS, але помилка неймовірно все-таки виникає. Я не маю можливості та ідеї, як рухатись вперед.

Ось помилки:

  • Фатальна помилка: Дозволений розмір пам'яті 536870912 байт вичерпано (намагався виділити 30 байт) у /home/example/public_html/sites/all/modules/views/views.module у рядку 416
  • Фатальна помилка: Дозволений розмір пам'яті 536870912 байт вичерпано (намагався виділити 108 байт) у /home/example/public_html/includes/menu.inc у рядку 2736

  • Фатальна помилка: Дозволений розмір пам'яті 536870912 байт вичерпано (намагався виділити 71 байт) у /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module у рядку 59

  • виділити 64 байти) у /home/example/public_html/sites/all/modules/views/includes/base.inc у рядку 93


Який ваш пік трафіку (сторінки / секунду). Також скільки даних (вузлів?) Подання намагається отримати назад?
cherouvim

подібна дискусія на drupal.org drupal.org/node/76156
Ануп Йосиф

2
Чи випадково у вас є вид, який повертає велику кількість результатів і для формату завантажує вміст замість полів? Я вже багато разів бачив цю перешкоду.
Джепедо

Привіт, народ! Дякую за відповіді. Хочу сказати, що веб-сайт перебуває в режимі обслуговування та містить лише декілька вмісту (вузлів) для тестових цілей. Цей сайт відвідують лише сканери Як я вже згадував у своєму дописі, обмеження збільшення пам’яті у рішенні php.ini, запропонованому у вузлі drupal.org/node/76156, у моєму випадку не допомогло. Для переглядів завантаження вмісту замість поля. Я хочу розібратися, як це
salift

1
Ви спробували перейти назад на Drupal 7.14? Якщо оновлення до Drupal 7.15 викликало цю проблему, то чому б не спробувати переключитися назад? Моя думка полягає в тому, що в одному з ваших модулів відбувається нескінченна рекурсія. Які ваші модулі, пов’язані з переглядами?
Джоннатан Елмор

Відповіді:


13

Я також останнім часом бив головою об стіну, коли проблеми з пам'яттю Drupal. Ось мої зібрані знання з теми:

1. Перегляди (можуть) використовують багато пам'яті

Мені подобаються деякі погляди (і Панелі, і CTools, і все, що merlinofchaos зачіпає його могутніми, могутніми пальцями), але можливо створити конфігурації з декількома відносинами, які використовують багато пам'яті. Якщо ви вимкнете перегляд і проблема з пам’яттю відміняється, це, ймовірно, погано сконструйоване подання, яке спричиняє проблему.

Що робити, якщо це Перегляд, і вам справді потрібен цей Вид для роботи? Спробуйте ввести його в код (через груповий експортер або функції; див. Нижче. Я вручну кодував функцію, схожу на представлення, щоб покращити продуктивність з дуже невеликим успіхом) для початку. Інша думка полягає в тому, щоб переглянути Перегляд іншим способом - якщо в кінцевому підсумку те, що ви отримуєте, це терміни таксономії, переконайтесь, що тип Погляду є поданням таксономії при його створенні; не створюйте Перегляд вмісту, який використовує взаємозв'язки, щоб визначити умови таксономії.

Тут також варто зазначити, що Панелі також нібито використовують багато пам’яті - я не дуже орієнтувався на це, тому не можу це підтвердити.

2. Переміщення матеріалів із бази даних в код - дуже хороша практика

Мені знадобилося кілька сайтів Drupal, щоб усвідомити це, але зберігати все, що створено за допомогою інтерфейсу користувача, в базі даних (особливо конфігурації панелей та панелей) - найгірша практика для Drupal. Чому? Це збільшує навантаження на базу даних і не може контролюватися версіями. Перший момент є особливо проблематичним щодо використання пам'яті - замість того, щоб просто завантажувати вміст із представлення даних із бази даних, сайт також повинен завантажувати самі компоненти перегляду. Це посилюється тим, як Drupal використовує таблиці: абстрагуючи все до п ятого ступеня, кожен біт функціональності Drupal використовує нову таблицю, в результаті чого деякі запити об'єднуються в мільярд таблиць разом. Це дає грижі людям з інформатики (застереження: посилання нерозумно), але насправді цього не можна уникнути за допомогою програмного забезпечення, такого як модульне та зручне для користувачів, як і Drupal.

Рішення? Використовуйте Bulk Exporter (в комплекті з CTools) або Особливості, щоб упакувати біти коду, що наразі перебувають у базі даних, як код модуля.

3. Теми також можуть їсти пам’ять

Чи є у вашій темі багато файлів шаблонів (тобто файли в імені теми / шаблони /)? Якщо так, пам'ять споживається щоразу, коли один із цих файлів завантажується. Якщо ви створюєте шаблони спеціально для того, щоб призупинити показ бітів Drupal, спробуйте:

  1. Зміна дозволів, щоб біт не відображався для певних ролей користувача, які не є адміністратором.
  2. Використання CSS для приховування елементів.

Перший вибір - це, очевидно, те, що ви хочете зробити для речей, що впливають на безпеку - ви не хочете використовувати CSS для приховування кнопки "редагування" для певних користувачів, лише щоб вони потім приховували її через Firebug чи будь-що інше.

4. Не перебирайте за борт модулів для внесків

Хоча іноді для сайту потрібна велика кількість модулів для надсилання повідомлень, не перебирайте за борт. Кожен увімкнутий (примітка: увімкнено. Відключені модулі не використовують жодної пам'яті) модуль використовує пам'ять. Це трохи очевидно, але варто відзначити незалежно.

5. VPS - це (іноді) брехня

На мій досвід, деякі недобросовісні хостингові компанії люблять намагатися підштовхнути сайти Drupal до серверів VPS - вони дорожчі, і це звільняє спільний хостинг для все більшої кількості веб-сайтів WordPress. Ситуація погіршується тим, що веб-хости часто не рекламують (або навіть охоче розповідають, якщо їх запитують), який верхній ліміт пам’яті для спільного хостингу.

На жаль, часто, якщо сайт не перебуває під інтенсивним трафіком і все ще виходить з ладу, проблема, ймовірно, має більше спільного з налаштуваннями Drupal, ніж будь-що інше. Натискання користувача на VPS просто замулює води та додає більше змінних для вирішення (Чи це конфігурація веб-сервера? Конфігурація PHP? Конфігурація гостя VPS? Конфігурація хоста VPS, навіть?).

6. Коли все інше не вдається, клонуйте до місцевого господаря і побийте його палицею

Це велика причина, чому люди використовують методологію розробки виробничих процесів з контролем версій - коли все інше не вдається, ви можете зробити дамп БД, git клонувати сайт на локальний тестовий сервер, а потім по-царському зіпсувати сайт на тестування сервера, не турбуючись про те, що насправді щось зламає на виробничому сервері.

Що стосується питань пам'яті, це, як правило, означає відключення модулів один за одним, поки той, що викликає проблему, не виявиться. Це також може вказувати на проблеми, пов’язані з веб-хостами - якщо сайт працює нормально під час локальної установки з пам'яттю, встановленою на щось розумне, наприклад, 128 Мб, то ви знаєте, що ваш веб-хостинг зламався.

тл; д-р

Моя кишка полягає в тому, що це викликає проблему. Спробуйте відключити це та очистіть кеш, перевірте, чи працює він.

Я також додам до цієї відповіді, як я думаю про інші речі, щоб спробувати ...


... і це саме та річ, на яку я сподівався, коли поставив щедрості з цього питання! Особливо 2. 110 реп для вас добрий сер :) Сподіваємось, це приверне корисні коментарі інших, які мають трохи інший досвід
user56reinstatemonica8

ps Я чув у різних місцях, що навіть відключені модулі використовують певний об'єм пам'яті для розбору файлів. Я бачив, як люди кажуть, що всі файли php / inc якимось чином розбираються, хоча це не здається правильним (скоріше лише файли інформації). Будь-яка ідея, чи є в цьому правда?
user56reinstatemonica8

Класно, дякую! Я впевнений, що Drupal досить сумлінний у пам'яті при завантаженні файлів - якщо ви запускаєте XHProf, кількість дзвінків, щоб зайняти file_scan_directoryдостатню кількість пам'яті. Я протестую деякі речі з розвитком цього, щоб підтвердити це.
aendrew

Якщо відключені модулі використовують будь-яку пам'ять, це досить несуттєво. Я переглянув, скільки пам’яті повідомляло Devel до та після видалення модуля - в той час як оновлення сторінки після видалення файлів показало невеликий (<1 МБ) сплеск, він повернувся до саме значень попереднього видалення під час наступного оновлення. Це змушує мене повірити, що Drupal a. Сканує каталог модулів під час завантаження, щоб побачити, чи є нові файли .info b. Додає деталі модуля до своєї systemтаблиці c. Завантажує будь-які модулі із записами в поле system.status 1. Якщо хтось може це підтвердити чи спростувати, я вдячний.
aendrew

2

Ви можете спробувати помістити PHP-профілер на зразок XHProf або Xdebug's вбудований профайлер, щоб перевірити, що відбувається в запиті.


Після того, як ви зрозуміли, для яких частин особливо потрібен об'єм пам'яті, який ви зробили. Крок 1. Насправді крок 2 намагається зрозуміти, для чого використовується стільки пам’яті та як зменшити її. Вище люди говорять про багато предметів у результаті тощо. Взагалі це процес, який неможливо описати просто.
Даніель Венер

1

Погляди - це свиня за пам’яттю. Кешування Drupal може допомогти. Drupal завантажує активні модулі, однак якщо вони створюють таблиці або мають інші об'єкти, які можуть зависати. Лише видалення видалить більшість артефактів. Ми використовуємо авторизацію / дозволи дозволу друпала і пишемо власні модулі в межах. Не найкраще, але продуктивність набагато краща та простіша у налаштуванні. Ми робимо те ж саме і для WP.


0

У моєму випадку проблема обмеження пам'яті була створена кеш-системою (модулі Boost і Boost Expire). Це дасть мені питання, щоб оновити модуль або представлення даних. Після відключення модулів Boost все працює нормально.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.