為什么Erlang / Elixir觀察者的內存使用次數不累加？

Question

我從Elixir開始，使用iex連接到遠程生產節點時觀察到一些奇怪的行為。

如下面的屏幕截圖所示，觀察者報告總共使用了92 MB內存。 但是，當您總結進程，原子，二進制文件，代碼和ets的內存消耗時，結果是： 〜69 MB

Processes  19.00 MB
    Atoms   0.97 MB (969 kB)
 Binaries  13.00 MB
     Code  28.00 MB
      ETS   7.69 MB (7685 kB)
-------------------
    Total  68.66 MB

因此，我的第一個問題是這多余的23 MB內存來自何處？ 我很確定這不僅是報告問題。 因為當我查看Kubernetes窗格的內存消耗時，它約為102 MB ，與觀察者顯示的數字一致。

我唯一能想到的是那23 MB尚未被垃圾回收。 我的假設有效嗎？ 如果是這樣，那么距離該容器啟動已經6個小時了。 我從一開始就一直在監視內存消耗。 現在不應該是垃圾收集嗎？

第二個問題：是否可以進行任何Erlang VM / Elixir配置調整以優化內存占用量？

Answer 1

我也一直在嘗試解決有關OTP應用程序中的內存管理的問題，其中一種對我特別有用的工具是Fred Hebert編寫的稱為recon的庫。 特別是recon_alloc模塊，它提供有關Erlang VM中內存使用情況的非常有用的信息。

丟失的兆字節

以下引用直接來自recon_alloc:memory()函數的文檔，並且可以為您提供正在發生的情況的見解：

由“已分配”報告的內存應與操作系統報告的大致匹配。 如果此數量相差很大，則可能是有人在Erlang自己的分配器之外直接在C中分配內存的信號-一個很大的警告信號。 當前，存在不計入此值的三個內存分配源：mseg分配器中的緩存段，分配為超級載體的任何內存以及在初始化過程中在初始化內存分配器之前分配的小塊內存。 另請注意，內存使用率低可能是內存碎片的跡象，在這種情況下，建議探究哪個特定的分配器出了問題。

因此，我認為額外的23 MB內存使用量可能是由於某些不希望有的分配導致的，或者可能是由於碎片造成的。

---

調整（非常小心/！\\）

關於第二個問題，Erlang中有一個名為erts_alloc的工具，該工具還描述了內存分配器的手動配置。 可以通過將命令行標志傳遞給仿真器來完成，例如：

erl +SOMEFLAG +SOMEOTHERFLAG

但是文檔中有一個很大的紅色警告，強烈建議與默認配置相比，弄亂這些標志會導致更糟糕的行為。

因此，如果確實是解決問題的唯一方法，我的建議是求助於這些修改。 在這種情況下，有一本關於Erlang運行時系統的書可以幫助我理解某些方面，因此我還建議您事先閱讀它。

注意：此處在黑暗中進行野外射擊，不能直接回答您的問題，但是仔細檢查二進制文件的狀態可能很有用，因為我發現觀察者報告了13 MB的空間。 根據它們的大小（小於或大於64字節），它們被存儲在進程堆中或通過引用進行訪問。 我遇到了第一種情況，其中堆滿了許多小二進制文件，最終導致系統崩潰。

---

在嘗試解決這些問題時，我發現了一些其他有用的資源：

• 弗雷德·赫伯特（Fred Hebert）撰寫的博客文章中的以下特定片段：

[erlang:garbage_collect(Pid) || Pid <- processes()].

它將立即在所有正在運行的進程上觸發GC。 就我而言，它創造了奇跡。 您也可以添加一個選項以異步方式調用它，這樣就不必在所有操作完成之前阻塞：

[erlang:garbage_collect(Pid, [{async, RequestId}]) || Pid <- processes()].

• 本文關於Erlang中的GC
• Erlang文檔中有關二進制文件的效率准則，其中提供了有用的實現細節。
• 東西變壞了：《憤怒》中的Erlang，這是另一本由......寫的免費電子書，是Fred Hebert。

希望這可以幫助 ：）