Процесс php-cgi жрет память более отведенного лимита

Буквально два дня назад решал подобную проблему. Решилось установкой 96Мб, но там такие выборки из баз данных присутствуют что мама-не-горюй.

Если скрипт жрет 320Мб - я бы попытался переписать скрипт...

во всех переменных скрипта максимум 2 мб, не может он столько жрать. Даже если не делать запросов к БД, потребляемая память не уменьшается.

Нарастание потребляемой памяти происходит постепенно, но в самих переменных скрипта обьем памяти не увеличивается.

Т.е. вы про чудеса в программировании только что написали?

Про те которых быть не может, вместо них баги только бывают....

Если есть переменных 4 штуки, каждая по 2Мб, то хоть убейся скрипт никак больше 10 Мб жрать не должен. А у вас 320 - как это обозвать?

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

Скрипт работает порядка 6 часов (~ 200 секунд процессорного времени), за это время процесс php-cgi с ~10мб возрастает до ~300мб и прерывается, в связи с поглощением всей свободной памяти.

Еще хотел спростиь, memory_limit ограничивает именно память процесса php-cgi? или память скрипта?

Поставьте для начала в скрипте переодический вывод memory_get_usage(0)

По крайней мере узнаете в php ли логическая ошибка или из самого интерпретатора "течет". Еще расширения могут быть дефектные. Они могут получать память из кучи php, а могут сами по себе.

Нетрадиционное это дело на php демоны писать. Поэтому низкая вероятность, что найдут и пофиксят специфичные для этого режима работы баги. Может переписать чтобы работало порциями?

memory_limit - ограничивает память интерпретатора скрипта. есть еще системные лимиты на память (те, которые ulimit).

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

А он так делает только если по крону стартует или если руками тоже?

mfl, А что за железка у вас может у вас впс оверселенный до безумия или пароц VIA C3, мы тут не экстрасенсы, озвучьте уж заодно аппарат

убица ап стену...

если б у меня скрипт PHP столько времени работал - первое что я сним сделал бы - удалил бы нафиг.

1. Разделяйте скрипт на части

2. Смотрите количество переменных в нем и по возможности втыкайте unset() везде.

3. Скрипт скорее всего циклично что-то грабит, если делает это не через CURL/сокеты - резать к чертовой матери не дожидаясь перитонитов.

4. Переменные живут все время работы скрипта, если вы циклично что-то грабите и у вас в процессе возникает $param[$i] который сам по себе не больше 2Мб, но таких сохранений образуется дофига, а вы их не удаляете сразу после итерации - вот вам и любое количество мегабайт на выходе. Выходы: - 1. сократить количество итераций, 2. писать переменные в базу/файлы, а не в память и т.п.

Да какая разница? Железка важна когда мы не знаем сколько пользователей будут юзать наши нагруженные сервисы. А когда мы собственными руками создаем PHP коды работающие по 6 часов - то тут никакая железка не поможет...

Возьми крутую, назавтра будем писать - помогите, что-то не так, скрипт работает 16 часов - жрут память...

Вывод - собственнные служебные задачи должны запускаться "на калькуляторе", если это не так - то их надо переписывать. И железки тут вторичны.

Сейчас буду проверять, спасибо за подсказку.

Без разницы. Итог один и тот же.

VPS: CPU 900 MHZ, Оперативка: 384 Mb

На счет оверселлинга, не замечал, сайты работают быстро.

да так и делаю, в каждой итерации пременные удаляются.

Именно так, обновление через CURL. Переменные по завершении итерации удаляются.

В общем. сейчас буду тестить с memory_get_usage(0).

Тогда вопрос, почему скрипт игнорирует значение установленное в memory_limit?

потому и игнорирует, что памяти вообще никакой нет.