Erlang SSL TCPサーバーとガベージコレクション

Question

編集：この問題は、SSLアクセラレーションとメモリリークの問題であるようです。あなたが長い（そのサーバー）プロセスを生きてきた、そしてクライアントがサーバ（RECV）にデータを送信する場合

は私が気づいた、Erlangのガベージコレクションは

サーバーがに（データを必要と呼ばれていない（またはめったに）を取得しませんプリフォームアクション）、データは可変長でもかまいません（「こんにちは」や「やっていますか？」などのメッセージが原因です）。このため、Erlangプロセスではゴミが蓄積されるようです。

これを適切に処理するには、Erlangプロセスがrecvデータに触れなければならないのですが、どうしてですか？あるいは、可変長データに触れるデザインを（ポートドライバに直ちに渡すような）より少ない時間で実現する必要があります。

データを処理するワーカーを作成することは悪い解決策です（何百万という接続）...そして、従業員を使用するのは基本的に同じでしょうか？だから私にはほとんどオプションがありません。サーバはそれが必要以上に長く、受信したメッセージに上保持している場合

おかげで...

Answer 1

誰もが同じボートで自分自身を見つけることができます。これは、一度に多くの接続でサーバーを叩くと知られています。おもう。

sslがないと、私のセッションは約8KBになり、リソースはGCのために期待どおりトリガーされています。 SSLを使用すると、〜150KBまで増加し、メモリは成長を続け、成長し、成長し続けます。

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

Answer 2

は、それがサーバーの実装のバグです。通常、サーバーは、要求の処理が終了した時点で、要求内のデータのすべてまたはほとんどの参照を忘れてしまい、データがガベージになり、最終的に収集されます。しかし、各リクエストのデータをプロセス状態のリスト、またはetsテーブルなどに張り付けると、メモリリークが発生します。

参照カウントによって処理されるため、64バイトを超えるバイナリでは例外が少しあります。また、メモリアロケータには、コレクションをまだ実行する必要がないように見えますが、使用されるバイト数そのようなバイナリによるオフ・ヒープはかなり大きくなる可能性があります。

Answer 3

あなたは大規模なSSL/TLSセッションテーブルに問題がある可能性があります。私たち（OTPチーム）は歴史的にいくつかの問題を抱えていました。なぜなら、あなたには何らかの制限メカニズムがないと、非常に大きくなるかもしれないからです。最新のsslバージョンでは、制限メカニズムの1つが壊れていましたが、このパッチでは簡単に修正されています。回避策として、効率を犠牲にしてセッションの再利用を無効にすることもできます。あなたはアーランGCの詳細が必要

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),