линукс, размер занимаемой памяти

[Evgeny M]

Как вы определеяете, сколько OTP скрипт ест памяти под линукс?

У меня получаются три цифры

erlang:memory() - total около 30M

просмотрщик процессов KDE - 70M

/proc/id/status - VmPeak около 230M

Какая из этих цифр - реальная память, при отсутсвии которой будет halt(0) и как этот размер получить в erlang скрипте? Считаем, что nif и портов, кроме тех что идут вместе с erlang/otp, нет. 

Последняя цифра, как я понимаю, это не фактически выделенная память, а некое виртуальное адресное пространство, но что будет если доступной памяти меньше?

[Max Lapshin]

Точного размера выделенной памяти нет: это как точные координаты электрона.

Вы лучше скажите, что именно вас интересует: как встроить на 32 мегабайта или как будет работать сервер с 64 гигабайтами?

[Evgeny M]

Меня интересует работа (полу)коробочного продукта на VPS с 512M RAM, при том, что там могут быть запущен и другие скрипты на пхп и прочем. 

вторник, 1 октября 2013 г., 16:55:19 UTC+4 пользователь Max Lapshin написал:

[Evgeny M]

Сразу скажу, что мониторить свободную память средствами memsup не получается, даже если сделать поправку на то, что тот выдает под линукс неправильные данные и всепересчитывать самому. VPS на OpenVZ сами по себе выдвют неверные цифры свободной памяти.

[Max Lapshin]

Я думаю, что вы вполне можете ориентироваться на rsize в top/ps.

[Evgeny M]

Ага,спасибо, посмотрю. Видимо придется как-то отличать один процесс beam от других.

Кстати хозяйке на заметку - при ограниченной памяти выполнять сколько-нибудь сложные и требующие памяти вещи в контексте процессов-акцепторов Cowboy нельзя, под нагрузкой память начинает уходить за 300М и больше. Приходится создавать отдельный пул воркеров 10-15 штук в которые акцепторы делают gen_server:call. А чтобы 
не переполнялась очередь самих акцепторов - еще и отдельный процесс, который следит за количеством необработанных запросов, чтобы в случае переполнения акцепторы сразу же отдавали 502. Получается чуть медленнее, зато предсказуемо.

вторник, 1 октября 2013 г., 17:20:32 UTC+4 пользователь Max Lapshin написал:

[Sergey Abramyan]

Используйте правильные VDS ;)

2013/10/1 Evgeny M <donped...@gmail.com>

Сразу скажу, что мониторить свободную память средствами memup не получается, даже если сделать поправку на то, что тот выдает под линукс неправильные данные и всепересчитывать самому. VPS на OpenVZ сами по себе выдвют неверные цифры свободной памяти.

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес erlang-russia...@googlegroups.com.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--

С уважением,

Сергей Абрамян

[Evgeny M]

Продукт коробочный, выбор VPS не за мной

вторник, 1 октября 2013 г., 17:40:35 UTC+4 пользователь Sergey Abramyan написал:

[Max Lapshin]

Пид пишите куда-нибудь, по нему и ориентируйтесь.

erlang:memory в принципе должен примерно то же самое показывать.

[Mikhail Gusarov]

erlang:memory будет показывать схожие цифры (минус размер исполняемого
кода самой VM) до тех пор, пока приложение не уйдет нечаянно в swap.

Best regards,
Mikhail Gusarov.


2013/10/1 Max Lapshin <max.l...@gmail.com>:

> Пид пишите куда-нибудь, по нему и ориентируйтесь.
>
> erlang:memory в принципе должен примерно то же самое показывать.
>

[Valentin Nechayev]

2013/10/1 Evgeny M <donped...@gmail.com>

Как вы определеяете, сколько OTP скрипт ест памяти под линукс?

У меня получаются три цифры

erlang:memory() - total около 30M

просмотрщик процессов KDE - 70M

/proc/id/status - VmPeak около 230M

Надо понимать, что mach-styled VM это такая обстановка, в которой всё сделано для того, чтобы не тратить лишнюю память, но вот адекватная оценка в такой VM очень тяжела.

Суммарная занятая VM включает в себя кучу неиспользуемых вещей типа полного содержания отмапленных библиотек (с теми функциями и данными, которые никогда не будут применены), арен аллокатора (glibc'шный с ходу берёт по 16M на ядро) и тому подобного, что существует только в описи адресного пространства процесса, но ничего не "ест" в реальности. (Смешное слово virtually.)

Часть из этого может быть резидентным (то есть реально лежать в RAM), но всё равно не влиять принципиально.

Я правильно понял, что это Linux? В таком случае самой адекватной мерой, jIMHO, является следующее: после полного старта процесса зафиксировать сумму *_Dirty из /proc/$pid/smaps и резидентный размер (его можно получить или там же, или из top с аналогами) и получить на основании предельного допустимого резидентного размера простой пропорцией на вычитание, сколько предельно допустимо sum_dirty. И в дальнейшем за ней и следить.
Этот метод у нас был отработан на Питоне, но думаю, что специфика Erlang для этого не сильно влияет. Из явной специфики Erlang может сработать только персональная куча процесса. Когда иголка пересиливает ношу верблюда, и требуется апгрейд последнего рывком до более крупной версии, например, от 400 до 600 мегабайт, и они оба вместе (на момент перелива) не влезают в доступный размер VM - нода падает целиком. Поэтому надо стараться не держать слишком толстых процессов, а запас VM должен быть таким, чтобы удержать эти расширения.

-netch-