我对Elixir和凤凰框架很陌生,所以我的问题可能有点愚蠢。
我有一个应用程序,Elixir + Phoenix Framework作为后端,Angular 2作为前端。我使用Phoenix Channels作为前端/后端交换的渠道。我发现了一个奇怪的情况:如果我从后端发送大块数据到前端,那么特定的通道进程内存消耗就会达到数百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条记录的集合,只是为了测试前端处理大量数据的能力,但却产生了副作用 - 我发现特定的通道进程内存消耗为167 Mb。所以我打开一些新的浏览器窗口,每个新的频道进程内存消耗增长到这个数量的"播放列表:列表"请求。
这是正常行为吗?我期望在数据库查询和数据卸载期间消耗大量内存,但即使在请求完成后它仍然相同。
更新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_protocol。
接下来我去了:
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之后进行(实际上在垃圾收集之后,当然 - 如果我运行:erlang.garbage_collection()与这些进程的pids结果是相同的):
{#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}]},
如果我不手动运行垃圾收集 - 内存&#34;永远不会&#34; (至少,我等了16个小时)变得自由了。
请记住:在从后端向前端发送消息后,我有这样的内存消耗,其中有7万条记录来自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)
我真的很感激这里的任何建议。我相信我不会发送如此大量的数据,但即使是较小的数据集也可能导致大量内存消耗,以防许多客户端连接。而且由于我没有编写任何棘手的事情,这种情况可能隐藏了一些更普遍的问题(当然,这只是一个假设)。
答案 0 :(得分:16)
这是二进制内存泄漏的经典示例。让我解释一下发生了什么:
您在此过程中处理了大量数据。这会增加进程堆,以便进程能够处理所有数据。在完成处理该数据之后,大部分内存都被释放,但堆仍然很大,并且可能保留对作为处理数据的最后一步而创建的大二进制的引用。 所以现在我们有一个由进程引用的大型二进制文件和一个包含很少元素的大堆。此时,进程进入缓慢的时段,仅处理少量数据,甚至根本不处理任何数据。这意味着下一个垃圾收集将会非常延迟(记住 - 堆很大),并且可能需要很长时间才能实现垃圾收集实际运行并回收内存。
为什么内存在两个进程中增长?由于查询数据库中的所有数据并对其进行解码,通道进程增长。一旦结果被解码成结构/地图,它就被发送到传输过程(牛仔处理程序)。在进程之间发送消息意味着复制,因此将复制所有数据。这意味着传输过程必须增长以适应它接收的数据。在传输过程中,数据被编码为json。这两个过程都必须增长,然后在那里保持大堆,无所事事。
现在来解决方案。一种方法是,当您知道自己刚刚处理了大量数据并且在一段时间内再也不会这样做时,明确地运行:erlang.garbage_collect/0
。另一种方法可能是避免首先增加堆 - 您可以在单独的进程中处理数据(可能是Task
)并且只关注最终的编码结果。在完成处理数据的中间过程之后,它将停止并释放其所有内存。此时,您只会在进程之间传递refc二进制文件而不会增加堆。最后,处理大量数据的常用方法始终是不需要的 - 分页。