Как ограничить максимальный размер выделенной памяти для данного процесса?

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

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

В библиотеке нашел как задать min_heap_size для процесса, но вот как задать max_heap_size?

Здравствуйте, valexey, Вы писали:

V>Как ограничить максимальный размер выделенной памяти для данного процесса?

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

V>А хотелось бы чтобы по исчерпанию максимально дозволенного объема памяти процесс спокойно упал.

V>В библиотеке нашел как задать min_heap_size для процесса, но вот как задать max_heap_size?

Минимальный размер — вещь статическая, а вот максимальный приведёт к доп. проверке, видимо поэтому его нет.
Но если очень нужно, то можно задать ручками, например как здесь. А если по-нормальному, то надо архитектурно (или ещё как) выправлять решение, которое к такому приводит.

V>>В библиотеке нашел как задать min_heap_size для процесса, но вот как задать max_heap_size?

К>Минимальный размер — вещь статическая, а вот максимальный приведёт к доп. проверке, видимо поэтому его нет.

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

К>Но если очень нужно, то можно задать ручками, например как здесь. А если по-нормальному, то надо архитектурно (или ещё как) выправлять решение, которое к такому приводит.

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

Предположим мы честно, не моргнув глазом, и доверяя авторитетам, взяли функцию подсчета оного факториала из вводного тьюториала по ерлангу (вот отсюда: http://erlang.org/doc/getting_started/seq_prog.html#2.2):

fac(1) ->
    1;
fac(N) ->
    N * fac(N - 1).

И вот пользователь возжелал подсчитать 0! (0 входит в ОДЗ факториала, так что пользователь имеет полное право это хотеть и любая фильтрация ввода это пропустит)...

Как от такого защититься архитектурно?

Здравствуйте, valexey, Вы писали:

V>Ну вот предположим мы считаем факториал. Один процесс допустим у нас отвечает за общение с пользователем (принимает от него запросы на подсчет факториала), обрабатывает и шлет полученные данные второму процессу который оный факториал и считает, и отдает подсчитанное первому процессу. Первый процесс это дело выводит скажем на консоль.

V>Предположим мы честно, не моргнув глазом, и доверяя авторитетам, взяли функцию подсчета оного факториала из вводного тьюториала по ерлангу (вот отсюда: http://erlang.org/doc/getting_started/seq_prog.html#2.2):
V>

V>fac(1) ->
V>    1;
V>fac(N) ->
V>    N * fac(N - 1).
V>

V>И вот пользователь возжелал подсчитать 0! (0 входит в ОДЗ факториала, так что пользователь имеет полное право это хотеть и любая фильтрация ввода это пропустит)...

V>Как от такого защититься архитектурно?

Входные данные от пользователя должны проверяться, у тебя же ОДЗ написанной функции не сходится с ОДЗ мат. функции, выявить это должны тесты хотябы. Или ты будешь выполнять произвольную функцию пользователя?
В общем не совсем понятна реальная задача, которая может соответствовать нарисованому тобой.

V>>Как от такого защититься архитектурно?

К>Входные данные от пользователя должны проверяться, у тебя же ОДЗ написанной функции не сходится с ОДЗ мат. функции, выявить это должны тесты хотябы. Или ты будешь выполнять произвольную функцию пользователя?

Предположим что ввод писал один человек (по спецификациям на факториал), а вычисление -- другой человек (тоже по спецификациям). Второй человек совершил ошибку.

К>В общем не совсем понятна реальная задача, которая может соответствовать нарисованому тобой.

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

Здравствуйте, valexey, Вы писали:

V>>>Как от такого защититься архитектурно?

К>>Входные данные от пользователя должны проверяться, у тебя же ОДЗ написанной функции не сходится с ОДЗ мат. функции, выявить это должны тесты хотябы. Или ты будешь выполнять произвольную функцию пользователя?

V>Предположим что ввод писал один человек (по спецификациям на факториал), а вычисление -- другой человек (тоже по спецификациям). Второй человек совершил ошибку.

К>>В общем не совсем понятна реальная задача, которая может соответствовать нарисованому тобой.

V>Люди делают ошибки. Хотелось бы чтобы в результате ошибки самое страшное что могло бы произойти -- крах отдельного процесса, но никак не всего приложения целиком.

Для этого служат тесты, как минимум (а в нормальной компании ещё и инспекции кода должны такое выявлять), перекладывать ответсвенность на рантайм за кривые руки разработчиков не хорошее решение имхо.
Съедание всей памяти — грубейшая ошибка, и надо быть очень отважным индусом, чтобы допускать такой код в рабочее приложение.
Хотя теоретически это несколько противоречит эрланговскому "fail fast".

Почему нельзя использовать erlang:system_monitor/2 с параметром {large_heap, Size}?

Здравствуйте, Курилка, Вы писали:

V>>Люди делают ошибки. Хотелось бы чтобы в результате ошибки самое страшное что могло бы произойти -- крах отдельного процесса, но никак не всего приложения целиком.

К>Для этого служат тесты, как минимум (а в нормальной компании ещё и инспекции кода должны такое выявлять), перекладывать ответсвенность на рантайм за кривые руки разработчиков не хорошее решение имхо.

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

К>Съедание всей памяти — грубейшая ошибка, и надо быть очень отважным индусом, чтобы допускать такой код в рабочее приложение.
К>Хотя теоретически это несколько противоречит эрланговскому "fail fast".

А также let it crash. Ибо оно в данном случае потянет за собой и всех остальных.
Если бы при создании процесса (или позже) можно было бы задать и макс_хип для него, это во-первых практически никак не повлияло бы на производительность (рост хипа всё же довольно редкая процедура, а если не редкая, то для того чтобы её сделать редкой есть параметр min_heap_size), а во-вторых позволило бы лучше изолировать процессы друг от друга и последовательно следовать стратегии let it crash.