Каково нормальное значение memory_limit (PHP как модуля Apache) для современных скриптов?

Question

[Роми]

Начал валиться движок с 500-й.

Стал копать - не хватает памяти - добавил memory_limit в ini с 128 до 256 mb - дижок воскрес.

Отсюда вопрос:

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

У него вообще морда не треснет от 256 метров на процесс? -) и надо срочно оптимизировать?

Или это я просто отстал от жизни? (такое тоже возможно, я давно не тюнил серваки)

Спасибо.

Answer 1

[Андрей Николаев]

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

Нельзя мести всех под одну гребенку и какого-то единого значения нет.
Есть рекомендованные значения вендора движка и есть "индивидуальные разработки", после которых естественно никто не проверяет характеристики. Код любого дополнительного модуля может в ходе своего выполнения требовать абсолютно разное количество памяти, но дело тут не в "современности" скриптов, а в банальной недальновидности или криворукости.

У него вообще морда не треснет от 256 метров на процесс? -)

В зависимости от настроек, например 1С-Битрикс может требовать 257/512 со старта, а некоторые нерадивые разработчики и вовсе увеличивают лимиты до 1ГБ. Здесь все зависит от характера выполняемой работы и подходить нужно индивидуально.

Каково нормальное значение memory_limit (PHP как модуля Apache)

Не существует единого "нормального значения", но практика показывает - чем меньше тем лучше.

Comments

[Роми]

В зависимости от настроек, например 1С-Битрикс может требовать 257/512 со старта

спасибо, это ответ!

[Ипатьев]

Роми, а у вас Битрикс?

[Роми]

Ипатьев, нет, но тоже composer-фреймворк

[Ипатьев]

Роми, извините, но во-первых, 1С-Битрикс не является никаким "composer-фреймворком"
А во-вторых, я так понимаю, что ваша логика следующая: ну если битрикс жрёт столько, то мне можно расслабиться?

Answer 2

[Григорий Васильков]

Мои веб-сайты (index.php) вкладываются в 32мегабайт.
Пережималки и отдавалки картинок в 16мегабайт (glide.php).
Консольные парсеры и работающие с "большими" данными - в 256мб (console.php).

Answer 3

[Sanes]

Плохой значит движок. С другой стороны 256 сегодня не роскошь.

Comments

[Роми]

мне бы как-то более однозначно хочется)))

[Sanes]

Роми, я везде ставлю 256мб и 30 сек. Хватает с большим запасом.

[Григорий Васильков]

Sanes, умножаем на число юзеров на сайте одновременно, вспоминаем что еще есть база данных, которой тоже надо (может даже пару гигабайт), и супервайзор и пару сервисов на линуксе, включая php-fpm, и вдруг понимаем, что сайт может держать 100 человек, и всё... Вспоминаем что у нас новостник типа onliner / washington post / novyny.live, где сидят 10тысяч и чешем голову "что же делать"

Программы работающие с ТЕКСТОМ (а именно такой программой является PHP) у наших дедов работали на компьютерах где оперативки было 256мегабайт или меньше. И работали ведь! И форумы даже писали.

[Sanes]

Григорий Васильков, это параметр PHP. При чем тут кол-во юзеров?

[Ипатьев]

Sanes, при том что веб-сервер работает не в однопоточном режиме?

[Sanes]

Ипатьев, и что? Вопрос про другое.

[Ипатьев]

То, что при многопоточном режиме в памяти может находиться больше одного процесса РНР. Два пользователя запросили страницу - уже 512 мегабайт отъели. 4 пользователя - гигабайт.
Это называется "арифметика". Которую желательно знать, занимаясь программированием.

Пока автора вопроса спасает то, что не все скрипты выбирают лимит. Но при увеличении нагрузки сервер может упасть уже по нехватке физической памяти.

[Sanes]

Ипатьев, вот такие кураторы PHP потом обращаются, чтобы им сервер настроили.

[Григорий Васильков]

о боже, увольте его кто-нибудь.

[Sanes]

Григорий Васильков, кого ты хочешь уволить?

[Григорий Васильков]

Sanes, гражданина, который за всю жизнь еще не разу не отхавал.

Пойми же, что "лимит памяти на один скрипт" умножается на "число скриптов" которое равно "числу юзеров". Если ты даешь 256мб одному скрипту - ты разработчикам даешь право писать код, который работает хуже чем должен. Когда у них падает по 32мегабайт памяти они должны делать вывод что написали криво.