Есть у сборщика мусора такая особенность, что он вызывается тем чаще, чем больше работает процесс. Кроме того, большие бинари собираются подсчетом ссылок. Если это объединить, то получается, что в системе может существовать процесс, через который проходят сообщения с большими бинарями и который почти ничего не делает (например, просто пересылает бинарь дальше). Пока у него не будет собран мусор, прошедшие через него бинари тоже не будут удалены. Сам я с такой проблемой на практике не сталкивался, но слышал рассказы о таком. Другой вариант, что где-то в состоянии хранится небольший бинарь, который был получен откусыванием кусочка от большого бинаря. Если не предпринимать специальных усилий, то он будет просто ссылкой на кусок большого и, соответсвенно, большой будет жить пока не собран маленький. Больше мне в голову так сходу ничего не приходит.
https://www.coletiv.com/blog/elixir-genserver-memory-issues/
Нашел проблему, но не могу понять как решить GenStage:consumer сохраняет данные в базу, после записывает в ets краткую информацию Если убрать запись в ets - то сборщик мусора корректно все подчищает Если оставить запись в ets - начинает течь, при этом сам размер ets не сильно растет Примерно так: model = Repo.insert!(...) :ets.insert(:organizations, {inn, {model.uuid, model.discharge_date}}) может быть, что в ets записываются ссылки на значения model и сборщик мусора поэтому не освобождает место из под model?
Обсуждают сегодня