长生不老药+凤凰通道内存消耗

Question

我是Elixir和Phoenix框架的新手，所以我的问题可能有点愚蠢。

我有一个应用程序，Elixir+Phoenix Framework作为后端，Angular 2作为前端。我使用Phoenix频道作为前端/后端交换的频道。我发现了一个奇怪的情况：如果我从后端向前端发送一大块数据，那么特定通道进程的内存消耗将高达数百MB。即使在传输结束后，每个连接（每个通道进程）也会消耗如此多的内存。

以下是后端通道描述中的代码片段：

defmodule MyApp.PlaylistsUserChannel do
  use MyApp.Web, :channel
  import Ecto.Query
  alias MyApp.Repo
  alias MyApp.Playlist
  # skipped ... #
  # Content list request handler
  def handle_in("playlists:list", _payload, socket) do 
    opid = socket.assigns.opid + 1
    socket = assign(socket, :opid, opid)
    send(self, :list)
    {:reply, :ok, socket}
  end
  # skipped ... #        
  def handle_info(:list, socket) do
    payload = %{opid: socket.assigns.opid}
    result =
    try do
      user = socket.assigns.current_user
      playlists = user
                  |> Playlist.get_by_user
                  |> order_by([desc: :updated_at])
                  |> Repo.all
      %{data: playlists}
    catch
      _ ->
        %{error: "No playlists"}
    end
    payload = payload |> Map.merge(result)
    push socket, "playlists:list", payload
    {:noreply, socket}
  end

我创建了一组包含60000条记录的记录，只是为了测试前端处理如此大量数据的能力，但有一个副作用——我发现特定通道进程的内存消耗为167Mb。因此，我打开了几个新的浏览器窗口，在"播放列表：列表"请求之后，每个新频道的内存消耗都增长到了这个数量。

这是正常行为吗？我预计在数据库查询和数据卸载过程中会有很高的内存消耗，但即使在请求完成后，它仍然是一样的。

更新1。因此，在@Dogbert和@michalmuskala的大力帮助下，我发现手动垃圾收集后，内存将被释放。

我试着用recon_ex库进行了一些挖掘，发现了以下示例：

iex(n1@192.168.10.111)19> :recon.proc_count(:memory, 3)
[{#PID<0.4410.6>, 212908688,
  [current_function: {:gen_server, :loop, 6},
   initial_call: {:proc_lib, :init_p, 5}]},
 {#PID<0.4405.6>, 123211576,
  [current_function: {:cowboy_websocket, :handler_loop, 4},
   initial_call: {:cowboy_protocol, :init, 4}]},
 {#PID<0.12.0>, 689512,
  [:code_server, {:current_function, {:code_server, :loop, 1}},
   {:initial_call, {:erlang, :apply, 2}}]}]

#PID<0.4410.6>是Elixir.Phoenix.Channel.Server，#PID<0.4405.6>是cowboy_procol。

接下来我去了：

iex(n1@192.168.10.111)20> :recon.proc_count(:binary_memory, 3)
[{#PID<0.4410.6>, 31539642,
  [current_function: {:gen_server, :loop, 6},
   initial_call: {:proc_lib, :init_p, 5}]},
 {#PID<0.4405.6>, 19178914,
  [current_function: {:cowboy_websocket, :handler_loop, 4},
   initial_call: {:cowboy_protocol, :init, 4}]},
 {#PID<0.75.0>, 24180,
  [Mix.ProjectStack, {:current_function, {:gen_server, :loop, 6}},
   {:initial_call, {:proc_lib, :init_p, 5}}]}]

和：

iex(n1@192.168.10.111)22> :recon.bin_leak(3)                  
[{#PID<0.4410.6>, -368766,
  [current_function: {:gen_server, :loop, 6},
   initial_call: {:proc_lib, :init_p, 5}]},
 {#PID<0.4405.6>, -210112,
  [current_function: {:cowboy_websocket, :handler_loop, 4},
   initial_call: {:cowboy_protocol, :init, 4}]},
 {#PID<0.775.0>, -133,
  [MyApp.Endpoint.CodeReloader,
   {:current_function, {:gen_server, :loop, 6}},
   {:initial_call, {:proc_lib, :init_p, 5}}]}]

最后是recon.bin_leak之后的问题进程的状态（当然，实际上是在垃圾收集之后——如果我用这些进程的pid运行：erlang.garabage_collection（），结果是一样的）：

 {#PID<0.4405.6>, 34608,
  [current_function: {:cowboy_websocket, :handler_loop, 4},
   initial_call: {:cowboy_protocol, :init, 4}]},
...
 {#PID<0.4410.6>, 5936,
  [current_function: {:gen_server, :loop, 6},
   initial_call: {:proc_lib, :init_p, 5}]},

如果我不手动运行垃圾收集，内存"永远不会"（至少，我已经等了16个小时）变为空闲。

只需记住：我从后端向前端发送了一条消息，其中有70000条记录是从Postgres中提取的。模型非常简单：

  schema "playlists" do
    field :title, :string
    field :description, :string    
    belongs_to :user, MyApp.User
    timestamps()
  end

记录是自动生成的，看起来像这样：

description: null
id: "da9a8cae-57f6-11e6-a1ff-bf911db31539"
inserted_at: Mon Aug 01 2016 19:47:22 GMT+0500 (YEKT)
title: "Playlist at 2016-08-01 14:47:22"
updated_at: Mon Aug 01 2016 19:47:22 GMT+0500 (YEKT)

如果有任何建议，我将不胜感激。我相信我不会发送这么多数据，但在许多客户端连接的情况下，即使是较小的数据集也可能导致巨大的内存消耗。由于我没有编码任何棘手的事情，这种情况可能隐藏了一些更普遍的问题（当然，这只是一种假设）。

Answer 1

这是二进制内存泄漏的经典示例。让我解释一下发生了什么：

在这个过程中，您需要处理大量的数据。这会增加进程堆，以便进程能够处理所有这些数据。处理完这些数据后，大部分内存都被释放了，但堆仍然很大，并且可能包含对作为处理数据的最后一步创建的大二进制文件的引用。因此，现在我们有一个由进程引用的大二进制文件和一个几乎没有元素的大堆。在这一点上，进程进入了一个缓慢的时期，只处理少量数据，甚至根本没有数据。这意味着下一次垃圾收集将非常延迟（记住，堆很大），并且可能需要很长时间，直到垃圾收集真正运行并回收内存。

为什么记忆在两个过程中增长？通道进程的增长是因为在数据库中查询所有数据并对其进行解码。一旦结果被解码为structs/map，它就会被发送到传输进程（牛仔处理程序）。在进程之间发送消息意味着复制，因此所有数据都会被复制。这意味着传输过程必须增长以适应其接收的数据。在传输过程中，数据被编码为json。这两个过程都必须增长，然后留下大堆，无所事事

现在来看解决方案。一种方法是，当您知道自己刚刚处理了大量数据，并且在一段时间内不会再这样做时，显式地运行:erlang.garbage_collect/0。另一个可能是从一开始就避免增加堆——您可以在一个单独的过程（可能是Task）中处理数据，只关心最终的编码结果。中间过程处理完数据后，它将停止并释放所有内存。在这一点上，您将只在进程之间传递refc二进制文件，而不增加堆。最后，总是有一种常用的方法来处理大量不需要同时处理的数据——分页。