Erlang ETS內存碎片

Question

我有一個erlang集群，其中erlang：memory（）“總”每天從空閑到繁忙時間在2-2.5GB之間。 ets的內存使用量約為440M，無論如何都保持不變。 ets中的數據是高度瞬態的，全天都在變化。 明天的數據可以保證與當今沒有共同點。

Linux負責人說Beam正在使用10 GB的數據。 free -m'used'同意這一點（機器實際上僅運行橫梁）。 系統的整體內存使用量有規律地增長，例如在16GB系統上每天增加1％。 節點之間存在一些差異，但不是很多，並且操作系統“已用”內存始終是erlang：memory（）總數的幾倍。

erlang：system_info（{allocator，ets_alloc}）顯示20個分配器。 大部分數據看起來像這樣（命令的完整輸出在此處 ）：

    {mbcs_pool,[{blocks,2054},
   {blocks_size,742672},
   {carriers,10},
   {carriers_size,17825792}]},

1）這是否意味着實際上742K字節（字？）的內存占用了17M的OS內存？ 2）正如這篇文章所暗示的，我們是否應該在VM args中添加“ + MEas bf”，以減少開銷？ 3）我還能做些什么來避免實際用完內存？

這是R17.5，但是我們將在下一個部署（本周）中遷移到R19.3。 我們在當前部署中沒有偵察功能，但是將在下一個部署中添加它。 同樣，無法想象這很重要，但是光束正在高山容器內運行。

Answer 1

萬一以后有人遇到：這實際上不是泄漏的內存。

erlang的默認內存分配器策略可能對您的使用不是最佳的，具體取決於您的操作以及取決於erlang配置為分配塊的方式。 事實證明，在某些情況下，由於分配器碎片，從erlang角度來看，“可用”內存不一定會立即釋放到OS。

這里對此做了一些解釋： http : //erlang.org/doc/man/erts_alloc.html

我們當時使用的erlang版本的默認分配器策略是aoffcbf（地址順序優先適合的載體最適合）。 在我們的案例中，這導致了很高的內存碎片（相當於10 + GB的開銷）。 對這些問題進行故障排除時， erlang:system_info(allocator)和erlang:system_info({allocator, Alloc})是您的朋友。 更改為aobff（最適合地址順序）可提高內存使用效率。 實際上，只要機器沒有物理內存用完就沒關系，但是對我們來說，我們正接近物理極限，這很危險。 並且您不想開始分頁。 使用aobff，即使節點運行了18個月，我們也從未超過4GB。 使用aoffcbf，我們將在幾周內通過10GB。

與以往一樣，YMMV取決於分配的塊的類型，大小等以及它們的生存時間。