%%% Garbage collection may take far longer to trigger for 100,000 refc binaries
%%% than for far fewer non-counted binaries, or may just as well never happen.
%%% In this case, the memory is never reclaimed and we have a leak.
%%%
%%% There exist decent work-arounds for this -- fiddling with hibernation,
%%% different GC strategies (tracking refc binary space and doing it manually),
%%% doing it on a per-process basis, and so on.
二进制引用回收可能需要很久或一直没有及时释放,这样的内存就一直不会使用,会导致内存耗光。因此需要我们监控并及时手工释放
https://github.com/Jasson/logplex/blob/master/src/logplex_leak.erl
Picking Up the Trash
Generally, refc binaries memory leaks can be solved in a few different ways:
- call garbage collection manually at given intervals (icky);
- manually track binary sizes and force GC, which defeats the purpose of having garbage collection in the first place and may do a worse job than the VM's virtual binary heap;
- stop using binaries (not desirable);
- or add hibernation calls when appropriate (possibly the cleanest solution).
引自https://blog.heroku.com/archives/2013/11/7/logplex-down-the-rabbit-hole
看完heroku上面的描述我决定还是选择监控然后手动回收。