Erlang SSL TCP服务器和垃圾回收

Question

编辑：问题似乎与SSL匹配和内存泄漏有关。

我已经注意到，如果您的Processes（它是服务器）的寿命很长，并且客户端将数据发送到服务器（recv），则Erlang垃圾回收永远不会被调用（或很少调用）

服务器需要数据（以执行操作），并且数据可以是可变长度的（由于诸如“ Hello”或“您好吗”之类的消息）。 因此，Erlang进程似乎会堆积垃圾。

您如何正确处理此问题，Erlang进程必须处理recv数据，所以这是不可避免的吗？ 还是您必须想出一种设计，使接触变长数据的次数更少（例如，立即将其传递给端口驱动程序）。

产生一个工人来处理数据是一个糟糕的解决方案（数百万个连接...），而使用工人基本上是一回事，对吗？ 因此，我几乎没有其他选择。

谢谢 ...

Answer 1

如果服务器将接收到的消息保留的时间超过所需时间，则可能是服务器实现中的错误。 通常，当请求完成处理后，服务器应该忘记对请求中数据的全部或大多数引用，然后数据将成为垃圾并最终被收集。 但是，如果将每个请求的数据粘贴在进程状态的列表中，或在ets表或类似表中，则会发生内存泄漏。

二进制大于64字节的情况有些例外，因为它们是通过引用计数来处理的，对于内存分配器，看起来好像还不需要执行收集，尽管这样的二进制文件可能很大。

Answer 2

以防万一有人发现自己在同一条船上。 一次锤击具有许多连接的服务器时，这是已知的/发生的。 我认为。

没有ssl，我的会话大约为8KB，并且按预期触发了GC的资源。 随着SSL的增加，它增加到了约150KB，并且内存在不断增长。

http://erlang.org/pipermail/erlang-questions/2017-August/093037.html

Answer 3

大型SSL / TLS会话表可能存在问题。 我们（OTP团队）历来对这些表存在一些问题，因为如果您没有一些限制机制，它们可能会变得很大。 遗憾的是，最新的ssl版本中的限制机制之一已被打破，但是此修补程序很容易修复它。 作为解决方法，您还可以牺牲一些效率并禁用会话重用。

diff --git a/lib/ssl/src/ssl_manager.erl b/lib/ssl/src/ssl_manager.erl
index ca9aaf4..ef7c3de 100644
--- a/lib/ssl/src/ssl_manager.erl
+++ b/lib/ssl/src/ssl_manager.erl
@@ -563,7 +563,7 @@ server_register_session(Port, Session, #state{session_cache_server_max = Max,

do_register_session(Key, Session, Max, Pid, Cache, CacheCb) ->
     try CacheCb:size(Cache) of
-   Max ->
+   Size when Size >= Max ->
    invalidate_session_cache(Pid, CacheCb, Cache);
_ ->    
    CacheCb:update(Cache, Key, Session),