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

Sereysethy TOUCH touch.sereysethy@REDACTED
Sun Sep 20 15:30:49 CEST 2015


Dear Andin,

To be honest, I am new to Erlang. So I am sorry sometimes for my naive
questions.

I just tried to fix and debug erlang code written by another person. I am
not sure yet where to look at. Since we dont use anything special about
SSL, beside we ask user browser to present certificate and pass it on to
our agent backend to process it. I look at the code, it seems nothing is
unusual.

You said this bug exists since Erlang 17? But why there were no memory leak
when it ran on Erlang 17.

I did as Jesper Louis Andersen suggested, and I saw there a big amount of
memory being used by ssl_manager.

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

And it keeps increasing overtime.

Can you let me know or pointing me to any documents on how to use observer
application?

Thanks, Sethy

On Sun, Sep 20, 2015 at 5:07 AM, Ingela Andin <ingela.andin@REDACTED>
wrote:

> Hi!
>
> 2015-09-19 18:34 GMT+02:00 Sereysethy TOUCH <touch.sereysethy@REDACTED>:
>
>> Hello,
>>
>> 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.
>>
>> I have read a post here [
>> http://erlang.2086793.n4.nabble.com/R18-Unbounded-SSL-Session-ETS-Table-Growth-td4713697.html]
>> which discussed about the ssl_session_cache ETS table which can become very
>> large.
>>
>>
> Well that bug is now fixed for 18.1 and in maint on github. This bug
> however has been around for a while so it is unlikly that this bug causes
> 18 to behave different from 17.
>
>
>
>> The process beam.smp can go up to more than 5G during a few hours of
>> executions.
>>
>> I am not yet sure what is the root cause of this issue.
>>
>> Does anyone know how to fix this? Or where should I look at?
>>
>
>
> You could try using the observer application to inspect the node, makes
> inspecting easy.
> Let us know your findings.
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
>
>
>>
>> Thanks, Sethy
>>
>> _______________________________________________
>> 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/20150920/cc31cea5/attachment.htm>


More information about the erlang-questions mailing list