Нашёл шутку:


Работает одинаково при $use = 1 и undef ( ) ;

`no DBI` память не освобождает.
Как избавиться от DBI?

Это сообщение отредактировал(а) tishaishii - 13.7.2012, 15:22

>Работает одинаково
Потому что use - команда времени компиляции, а if - времени исполнения. И ваш код, на самом деле, выглядит как



Почитайте perldoc -f use, perldoc perlmod.

>память не освобождает
И не должно. Что вы вообще хотите сделать?

Это сообщение отредактировал(а) DurRandir - 13.7.2012, 17:51

Освободить память. Например, за счёт выгрузки модуля, который больше не нужен.
Предполагается много процессов одного и того же.

perl помнится, освобождать память не особо любит

1. Отличный кандидат на XY-вопрос месяца) 
2. http://stackoverflow.com/questions/9145990...rom-child-stack - там не всё верно, но основную мысль доносит)
3. На десерт) Если перл собран с usemymalloc, то в систему он память не вернёт никогда (но с лёгкостью переиспользует для своих нужд)

Class::Unload. Освободит ли это память хотя бы для переиспользования непонятно, нужно проверять.

Так вот. Без всяких if'ов выглядит, думаю: 

Спасибо, может быть,  всё-таки будет полезен модуль Class:Unload.
Выполнил скрипт: смотрел htop, никаких изменений не видел. Возможно, память для повторного использования освобождается. Сегодня в течении дня протестирую получше.

Итого. Вижу подходы к решению:

•  разделять на потоки, вместо форков ;
•  разделять на сервера по задачам.

Комментарий к 1му варианту. У меня сейчас в обработке предполагаются ошибки с выходом. Придётся перестраивать взаимодействие и много-много тестировать. И всё равно, в итоге, дополнительно делить на процессы. Потенциально, потребление ресурсов можно свести к какому-то желаемому минимуму.
Комментарий ко 2му варианту. Тщательно проектировать, либо может ресурсов съесть больше, или раскидывать по разным машинам. Всё равно, тщательно проектировать.
Вывод: оба варианта требуют достаточно много времени для доработки.

А вот если в главном процессе использовался какой-то модуль, а в дочернем этот модуль может быть нужен, а может быть нет (зависит от запроса), то что делать?

Это сообщение отредактировал(а) tishaishii - 16.7.2012, 07:26

У меня когда была проблема с использованием тяжёлого, но редкоиспользуемого модуля, я её решил через system, т.е. написал отдельный скрипт на perl-e и вызывал его как внешнюю программу.

Во всех других случаях перл даже выгружая модуль память не отдаёт.

Именно из-за политики складывания про запас надо так же быть внимательным с хранением больших данных в переменных.

То есть, вы предлагаете использование отдельного процесса для вычислений. Вот я подумал, в общем случае, сервер для этого может подойти. Хотя... если мелочь, конечно, с system проще. Вот как быть с DBI?
Или Config::General? Парсит конфиг, допустим, выдаёт его в каком-то формате в STDOUT и пишет в STDERR ошибки. Основной процесс читает STDOUT, который снова нужно парсить?

Это сообщение отредактировал(а) tishaishii - 16.7.2012, 07:30

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

Весь вывод внешнего скрипта через STDOUT автоматически попадёт в Вашу переменную:

my $answ = `perl скрипт.pl -a -b`; # тут обратные кавычки

>разделять на потоки, вместо форков
Запасся попкорном

Это сообщение отредактировал(а) DurRandir - 16.7.2012, 14:11

Сообщи что-нибудь, что поможет.
[hr]

Протестировал Class::Unload. До сих пор точно сказать не смогу, но, кажется, всё-таки, освобождает память для повторного использования. Спасибо.