Zend php memory memory_limit

Question

Все,

Я работаю над веб-приложением на основе Zend Framework. Мы продолжаем сталкиваться с ошибками нехватки памяти на нашем сервере разработки:

Допустимый объем памяти XXXX байтов исчерпан (пробовал ГГГГ ...

Мы продолжаем увеличивать memory_limit в php.ini, но теперь он превышает 1000 мегабайт. Что такое нормальное значение memory_limit? Каковы обычные подозрения в php / Zend для нехватки памяти? Мы используем Propel ORM.

Спасибо за помощь!

Обновление Я не могу воспроизвести эту ошибку в моей среде Windows. Если я установлю значение memory_limit на низкое значение (скажем, 16M), я получу ту же ошибку, но «попытка выделить» всегда является чем-то разумным. Например: (попытался выделить 13344 байта) Если я установлю очень низкий объем памяти на сервере (Fedora 9) (например, 16M), я получу то же самое. последовательные, разумные ошибки нехватки памяти. Однако, даже если на нашем сервере установлен очень высокий предел памяти (например, 128 МБ), возможно, раз в неделю, я получу сумасшедшую огромную ошибку памяти: (попытался выделить 1846026201 байт) Я не знаю, может ли это пролить больше света на то, что происходит. Мы используем Propel 1.5. Похоже, что настоящий релиз выйдет позже в этом месяце, но не похоже, что у кого-то еще есть такая проблема. Я не знаю, в чем проблема с Propel. Мы используем Zend Server с php 5.2 на Linux и 5.3 на локальном компьютере.

Есть еще идеи? У меня есть билет, чтобы установить Xdebug в Linux.

Спасибо

-rep

Answer 1

Вообще говоря, с PHP 5.2 и / или PHP 5.3 я склонен считать, что более чем 32M для memory_limit "слишком много":

• Используя Frameworks / ORM и тому подобное, 16M часто недостаточно
• Использование 32M обычно достаточно для веб-приложений, над которыми я работаю (типичные сайты)
• Использование более 64M означает, что сервер не сможет обрабатывать столько пользователей, сколько нам хотелось бы.

Когда дело доходит до сценария, достигающего memory_limit, обычной проблемой является попытка загрузить слишком много данных в память; пара примеров:

• Загрузка большого файла в память с помощью таких функций, как file или file_get_contents или функций / классов, связанных с XML
• Создание слишком большого массива данных
• Создание слишком большого количества объектов

Учитывая, что вы используете ORM, вы можете оказаться в ситуации, когда:

• Вы выполняете SQL-запрос, который возвращает много строк
• Ваш ORM конвертирует каждую строку в объекты, помещая их в массив
• В этом случае решением было бы загрузить меньше данных
  • с использованием нумерации страниц, например
  • или пытаться загрузить данные в виде массивов вместо объектов (я не знаю, возможно ли это с Propel - но это с Doctrine; так что, возможно, у Propel есть какой-то способ сделать это тоже?)

Answer 2

Я думаю, это как-то связано с развертыванием из круиз-контроля. Я получаю очень высокую (порядка гигов) ошибку памяти, когда кто-то развертывает новый код (или только после того, как новый код был развернут). Это также имеет немного смысла, так как ошибка всегда указывает на строку, которая является «require_once». Каждый раз, когда я получаю сообщение об ошибке: Неустранимая ошибка: недостаточно памяти (выделено 4456448) (попытка выделить 3949907977 байт) в /directory/file.php в строке 2

Я заменил строку require_once на: class_exists ('Ingrain_Security_Auth') || требовать ( 'вселить / Безопасность / auth.php');

Я заменил эту строку в 3 файлах, и у меня больше не было проблем с памятью. Кто-нибудь может пролить свет на то, что может происходить? Я использую круиз-контроль для развертывания.

Answer 3

У вас происходит одна из двух вещей, возможно, обе:

1. У вас есть сбежавший процесс, который не заканчивается, когда он должен быть.
2. У вас есть алгоритмы, которые отбрасывают большое количество данных, таких как огромные строки, массивы или объекты, и делают ненужные копии вместо того, чтобы обрабатывать только то, что им нужно, и отбрасывать то, что они не делают.

Answer 4

Что именно делает ваше приложение, когда ему не хватает памяти. Там может быть много причин для этого. Я бы сказал, что наиболее распространенным является выделение слишком большого количества данных в массив. Ваше приложение что-то делает в этом направлении.