Увеличение PHP memory_limit. В какой момент это становится безумным?

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

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

Аппарат имеет 2 ГБ ОЗУ, а memory_limit в настоящий момент установлен в 1,5 ГБ. Мы можем легко добавить больше оперативной памяти в машину (и в любом случае).

У других возникли такие проблемы? и каковы были решения?

Ответ 1

Конфигурация для memory_limit PHP, работающего как модуль Apache на веб-страницах сервера, должна учитывать, сколько всего процесса Apache вы можете иметь одновременно на машине - см. параметр конфигурации MaxClients для Apache.

Если MaxClients равно 100, и у вас есть 2000 MB или RAM, очень быстрый расчет покажет, что вы не должны использовать более 20 МБ * (потому что 20 МБ * 100 клиентов = 2 ГБ или ОЗУ, т.е. общая сумма памяти вашего сервера) * для значения memory_limit.

И это без учета того, что на одном сервере есть, вероятно, другие вещи, такие как MySQL, сама система... И этот Apache, вероятно, уже использует некоторую память для себя.

Или курс, это также "наихудший сценарий", который считает, что каждая страница PHP использует максимальный объем памяти, который он может.

В вашем случае, если вам нужен такой большой объем памяти только для одного задания, я бы не увеличил memory_limit для PḦP, работающего как модуль Apache.

Вместо этого я запустил бы это задание из командной строки (или через задание cron) и задал бы более высокий memory_limit конкретный в этом одном и только случае.

Это можно сделать с помощью опции -d php, например:

$ php -d memory_limit=1GB temp.php
string(3) "1GB"

Учитывая, что в этом случае temp.php содержит только:

var_dump(ini_get('memory_limit'));

На мой взгляд, это безопаснее, чем увеличение memory_limit для модуля PHP для Apache - и это то, что я обычно делаю, когда у меня есть большой набор данных, или какой-то действительно тяжелый материал, который я не могу оптимизировать или разбивать на страницы.

Если вам нужно определить несколько значений для выполнения CLI PHP, вы также можете сказать ему использовать другой файл конфигурации вместо стандартного php.ini с опцией -c:

php -c /etc/phpcli.ini temp.php

Таким образом, у вас есть:

/etc/php.ini для Apache с низким memory_limit, низким max_execution_time,...
и /etc/phpcli.ini для партий, запущенных из командной строки, практически без ограничений

Это гарантирует, что ваши партии будут работать - и у вас по-прежнему будет безопасность для вашего сайта (memory_limit и max_execution_time).

Тем не менее, если у вас есть время для оптимизации вашего script, вам следует; например, в такой ситуации, когда вам приходится иметь дело с большим количеством данных, разбиение на страницы является обязательным, -)

Ответ 2

Вы пытались разбить набор данных на более мелкие части и обрабатывать только одну часть в то время?

Если вы извлекаете данные из файла диска, вы можете использовать функцию fread() для загрузки меньших фрагментов или некоторые тип небуферизованного db-запроса в случае базы данных.

Я не проверил PHP с v3.something, но вы также можете использовать форму облачных вычислений. 1 ГБ набор данных кажется достаточно большим, чтобы обрабатываться на нескольких машинах.

Ответ 3

Учитывая, что у вас есть проблемы с памятью с вашим script, которые нуждаются в исправлении, и вы ищете только краткосрочные решения, тогда я не буду обсуждать пути перейти к профилированию и решить проблемы с памятью. Похоже, вы доберетесь до этого.

Итак, я бы сказал, что основные вещи, которые вы должны иметь в виду:

Общая загрузка памяти в системе
Возможности ОС

PHP - это только один небольшой компонент системы. Если вы позволите ему съесть огромное количество вашей оперативной памяти, тогда пострадают другие процессы, которые, в свою очередь, могут повлиять на script. Примечательно, что если вы извлекаете большое количество данных из базы данных, то для создания наборов результатов для ваших запросов для вашей СУБД может потребоваться большая часть памяти. В качестве быстрого исправления вы можете захотеть идентифицировать любые запущенные вами запросы и как можно скорее освободить результаты, чтобы дать себе больше памяти для длительного прогона работы.

С точки зрения возможностей ОС вы должны иметь в виду, что 32-разрядные системы, на которых вы, скорее всего, работаете, могут обращаться только до 4 ГБ ОЗУ без специальной обработки. Часто ограничение может быть намного меньше в зависимости от того, как оно используется. Некоторые чипсеты и конфигурации на базе Windows могут иметь менее 3 ГБ в системе, даже с 4 ГБ или более физически установленными. Вы должны проверить, насколько ваша система может обратиться.

Вы говорите, что вы увеличили ограничение памяти несколько раз, поэтому, очевидно, эта работа становится все больше и больше по охвату. Если вы до 1.5 ГБ, то даже установка 2 ГБ больше оперативной памяти звучит так, как будто это будет короткая отсрочка.

У других есть такой вид вопрос? и каковы были решения?

Думаю, вы, наверное, уже знаете, что единственное реальное решение - сломать и потратить время на оптимизацию script в ближайшее время, иначе вы закончите работу, которая будет слишком большой для запуска.