Evrone
1181

Какие преимущества дает сборка мусора в Erlang

Одна из особенностей языка Erlang, которая дает ему преимущества, — это процесс управления сборкой мусора. Инженеры Evrone активно используют Erlang в проектах компании.

В закладки

О том, как происходит сбор мусора, рассказал ведущий разработчик нашей компании Борис Кузнецов в докладе на главной ежегодной конференции Erlang сообщества: CodeBeam STO. Давайте разберемся!

Эволюция сборщика мусора

Erlang — это функциональный язык программирования с динамической типизацией. Его главной особенностью является работа на уровне отдельных процессов. Процессоры компьютеров практически перестали развиваться в сторону увеличения частоты, и рост производительности идет за счет увеличения количества ядер. Программы, написанные на Erlang, как раз позволяют использовать всю мощность многоядерных процессоров.

Алгоритм сборки мусора

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

Процессы в Erlang

Центральная точка текущей реализации архитектуры выполнение кода — планировщик, который стартует на каждом ядре операционной системы с индивидуальной очередью запуска процессов. На каждый процесс отведен определенный лимит (количество вызовов функций), в рамках которого процесс выполняет свою работу, после чего начнется выполнение следующего в очереди.

Процесс в виртуальной машине Erlang — полностью изолированная сущность, которая не связана с процессами ОС и имеет свою собственную память, в ней размещается стек (инструкции по работе процесса) и куча (heap - данные, необходимые для работы процесса).

Процесс состоит из двух частей:

  • Отдельный блок-контроллер, содержащий общую информацию о процессе (ссылки на область памяти, статистика, счетчики и т. д.).
  • Область памяти, на которую ссылается контроллер процесса.

Когда нужен сборщик мусора

Когда не хватает места для размещения нового объекта, запускается сборщик мусора (Garbage Collector, GC), который уничтожает ненужные для дальнейшего выполнения программы данные, после чего код продолжает работу.

В Erlang используется GC, разделяющий объекты в куче на поколения молодые и те, которые пережили хотя-бы два цикла сборки мусора (долгоживущие). Долгоживущие объекты обрабатываются сборщиком мусора примерно раз в 65 тысяч циклов.

Стандартный цикл

Малый цикл Garbage Collector выделяет в current heap объекты, на которые больше нет ссылок и которые не нужны для продолжения работы процесса. Процедура происходит в несколько этапов:

  • Сборщик находит корневые объекты (в терминологии Erlang — root objects), то есть различные места, которые могут ссылаться на данные в памяти процесса (словарь процесса, очередь сообщений, данные об ошибке и т. д.). GC переносит в новую область памяти только те объекты, на которые кто-то ссылается.
  • Затем сборщик проходится по перенесенным объектам в новой области памяти и переносит все данные, на которые они ссылаются.
  • В новую область переносится стек, после чего цикл сборки мусора завершается, а объекты, на которые не осталось ссылок, уничтожаются. Пережившие процедуру данные помечаются отдельной меткой, чтобы при следующем цикле сборки мусора перенестись в область памяти для взрослых объектов (то есть тех, что пережили хотя бы два цикла) — old heap.
Обзор механизмов сборки мусора в Erlang

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

Что делать со старыми объектами

Особенность Erlang в том, что сборщик мусора возвращается к объектам старого поколения (major collection, живут в отдельной области памяти) лишь через ~ 65 тыс. стандартных циклов. В ходе этого процесса сборщик мусора выделяет новую область памяти и переносит в нее стек, актуальные объекты из области памяти для долгоживущих объектов и молодые объекты из текущей памяти процесса.

Так как за один раз обрабатывалось большое число объекта, в редких случаях этот процесс мог занимать продолжительное время (больше 1мс), что негативно влияло на планировщик процессов, так как он не мог учитывать данное время в своей логике, так как устанавливает лимит выполнения только на количество вызванных функций. Раньше в Erlang существовал баг, который мог привести к краху процесса, если он выполнялся слишком долго. Причиной могли быть либо долгая сборка мусора, либо вызов NIF (native implemented functions, внешних библиотек).

Для решения этих проблем был добавлен второй тип планировщика для каждого ядра — Dirty scheduler. Он также запускается на каждом ядре ОС как и обычный, но такой тип планировщика использует общую очередь на все ядра. В нее попадают процессы, которые ожидаемо могут долго выполняться, обходя лимиты выполнения (NIF либо долгий цикл сборки). Если система обнаруживает, что в области памяти не хватает места, а следующий вызов GC может потенциально занять много времени, то процесс будет помечен на перенос в dirty job queue и ему будет выделен небольшой участок памяти необходимый для того, чтобы процесс продолжил свою работу и израсходовал доступный ему лимит на выполнение.

Когда нужен Garbage Collector?

Чтобы предоставить процессу необходимую прямо сейчас память (так как у него еще остался лимит выполнения), используется сборка мусора с задержкой (Delay GC). Технология помечает текущую кучу как abandoned heap и выделяет новую область, в которой будет доступно необходимое процессу место под новые объекты с небольшим запасом. Если процесс израсходует выделенную область и у него останется лимит на выполнение, то ему будут добавляться еще новые области пока у процесса будет оставаться лимит на выполнение (reductions). В терминологии исходного кода сборщика мусора, такие области памяти называются heap fragments.

Рост памяти

По каким правилам растет память процесса? В текущей, 21-й версии Erlang это выглядит так:

  • Первые 23 увеличения происходят по Фибоначчи с исходными числами 12 и 38.
  • После 23: увеличение размера памяти процесса на 20%.

После того, как в новую область памяти перенесли актуальные объекты, может оказаться что их стало значительно меньше чем ожидалось. В таком случае происходит уменьшение выделенного фрагмента по следующему правилу — берется большее значение из чисел: 1/8 от размера old heap или в три раза больше, чем необходимо.

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

Идеально для высококонкурентных программ

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

Виртуальная машина Erlang является достаточно зрелым программным продуктом, проверенным временем в системах мягкого realtime. Erlang дает преимущества при создании надежных, высококонкурентных распределенных программ в сфере телефонии, передачи потокового видео, мобильного интернета, сервисов обмена сообщениями и так же в различных веб-проектах.

{ "author_name": "Evrone", "author_type": "editor", "tags": [], "comments": 12, "likes": 29, "favorites": 13, "is_advertisement": false, "subsite_label": "evrone", "id": 75458, "is_wide": true, "is_ugc": false, "date": "Tue, 16 Jul 2019 12:18:26 +0300" }
{ "id": 75458, "author_id": 250259, "diff_limit": 1000, "urls": {"diff":"\/comments\/75458\/get","add":"\/comments\/75458\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/75458"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 250259, "last_count_and_date": null }
12 комментариев

Популярные

По порядку

Написать комментарий...
6

немного необычно для VC, но прочитал с удовольтствием

думаю, тут достаточно технарей, чтобы оценить

Ответить
2

А можно поинтересоваться, что Вам понравилось? Ужасно ведь изложено. Для сравнения https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html или https://ru.wikipedia.org/wiki/Erlang#%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D0%B5_%D0%BE%D1%81%D0%BE%D0%B1%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8

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

P.s. Самый лучший вариант, на мой взгляд, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.7791&rep=rep1&type=pdf

Ответить
1

я на другом стеке вообще сижу, на языке с GC, поэтому для поверхностного ознакомления с другими технологиями счел достаточным. Даже не Эрланг как таковой интересен, а логики разных GC

Ответить
1

Да наконец-то на VC что-то для технарей появилось!
Знаете как тяжело смехуечки для большинства статей программисту выдумывать?!

Ответить
1

3 ссылка на общее описание алгоритма, 2 на википедию, где вообще 0 информации о работе GC в erlang, только 1 ссылка на ту же тему, но тоже на английском, вы точно уверены что там лучше изложено?

А по статье - хорошо, конечно, но имхо сайт не тот, это формат хабра, скорее.

Ответить
0

Прежде, чем опубликовать ссылки я прочел содержимое. Там не на эльфийском написано. Я не утверждал, что содержимое этих статей один в один, я предложил для сравнения подачу материала.

И да, я считаю, что авторы Erlang'а Robert Virding и Joe Armstrong лучше изложили то, как построен их GC.

Ответить
2

Это не для технарей написано, а для домохозяек. То есть как раз попали в аудиторию.

Ответить
1

как говорил Эрлих Бахман:
- ну и самомнение

Ответить
1

Спасибо ;) просвещаем менеджмент ;)

Ответить
1

А для каких целей используете erlang в компании?

Ответить
0

Для написания микросервисов, также как Go и Rust

Ответить
0

Я так понимаю, чистый erlang, не elexir?

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления
{ "page_type": "default" }