[erlang-questions] Erlang OTP 18 memory leak / SSL

Ingela Andin ingela.andin@REDACTED
Mon Sep 21 11:54:13 CEST 2015


Hi!


2015-09-21 10:09 GMT+02:00 Sereysethy TOUCH <touch.sereysethy@REDACTED>:

> Hello,
>
> One question, why did my application work fine on Erlang 17.5.x branch?
>
>
Well I am not sure what your application does.

If you have a client application that spawns a lot of parallel connections
to the same host, not waiting for one to succeed before spawning,
the client session table could grow a lot. However I have implemented a
feature to only save unique TLS-sessions in this senario to avoid this, and
there was a bug so that this feature did not work, that I have fix in the
maint branch. This bug however was in 17 as well as 18.

However the ets info you sent suggest you have a server application and
then setting session_liftime can help keeping the servers session table
smaller. This also is true for clients, that can get a big table also
through connecting to many diffrent servers.

Maybe your application can be both a TLS-client and server? There is no
obvious reason from what you told us so far that it should work better in
17 then 18.


If I want to set this session_lifetime option, where should put it?
>
>
It is an application environment setting. Search for app in the docs.


So there is no use that I should build the erlang 18 from maint branch?
>
>

It is always a good thing to try the latest version, and if you still have
a problem it would be good if you could try providing a way to reproduce
the problem.

Regards Ingela Erlang/OTP tema Ericsson AB




> Thanks,
> Sethy
>
> On Mon, Sep 21, 2015 at 2:51 PM, Ingela Andin <ingela.andin@REDACTED>
> wrote:
>
>> Hello,
>>
>> 2015-09-20 15:24 GMT+02:00 Sereysethy TOUCH <touch.sereysethy@REDACTED>:
>>
>>> Hello,
>>>
>>> I did as what you told me by getting a shell console on the node.
>>>
>>> I run memory(). and see ets ate the most memory. And it increased
>>> overtime. I run ets:i(). and I found out the ssl_manager took a big chunk
>>> of what memory used.
>>>
>>> 32794           client_ssl_otp_session_cache ordered_set 0      89
>>> ssl_manager
>>> 36891           server_ssl_otp_session_cache ordered_set 1564   67995
>>>  ssl_manager
>>> 40993           httpc_manager__session_cookie_db bag   0      299
>>>  httpc_manager
>>>
>>> So I think there is a problem with ssl_manager in Erlang OTP 18.
>>>
>>> Any workarounds?
>>>
>>>
>>
>> Ok, the bug I fixed with the session table is on the client side.  But
>> your big ets table is on the server side.
>> Session data is by default  fairly long lived (24 h that is the max
>> recommended time to keep a session by the RFC),
>> you can set the ssl application variable session_lifetime to make  its
>> lifetime shorter which should mitigate your problem.
>> We have a backlog item to make a configurable threshold of max sessions
>> allowed to be stored in the table, which I am sure will be
>> implemented fairly soon but alas  not for 18.1.
>>
>> Regards Ingela Erlang/OTP Team - Ericsson AB
>>
>>
>>
>>> Sethy
>>>
>>> On Sun, Sep 20, 2015 at 2:22 AM, Jesper Louis Andersen <
>>> jesper.louis.andersen@REDACTED> wrote:
>>>
>>>>
>>>> On Sat, Sep 19, 2015 at 6:34 PM, Sereysethy TOUCH <
>>>> touch.sereysethy@REDACTED> wrote:
>>>>
>>>>> I just recently updated Erlang to latest version OTP 18 on Ubuntu
>>>>> server. It uses cowboy (websocket), ranch, ssl, erlydtl & rabbitmq. It used
>>>>> to work fine in OTP 17. The program is correctly compiled but during the
>>>>> execution the memory kept increasing. I need to restart the process every
>>>>> one or two hours to free some memory.
>>>>
>>>>
>>>> 1. Get a shell console on the node
>>>> 2. call 'memory().' in the shell
>>>> 3. If it reports ets as the winner, call
>>>> 4. ets:i().
>>>>
>>>> This will give you a nice overview for where to look and verify it is
>>>> the SSL problem.
>>>>
>>>>
>>>> --
>>>> J.
>>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150921/d711e72a/attachment.htm>


More information about the erlang-questions mailing list