[erlang-questions] ssl_session_cache: trouble + questions

Lukas Larsson lukas@REDACTED
Wed Dec 9 13:39:06 CET 2015


You did not mention what version of ssl that you are using? If you do not
have the latest version, please have a look at the release notes in ssl and
see if any of the fixes in there applies to you. There are fixes made in
ssl that relate to a very large session cache.


On Tue, Dec 8, 2015 at 1:15 PM, Danil Zagoskin <z@REDACTED> wrote:

> Hi!
> Recently our servers started to consume lots of SYS CPU.
> Inside a VM top processes (by reductions per second) were ssl session
> validators.
> Most popular current function in runnable processes was
> calendar:datetime_to_gregorian_seconds/2.
> Also gproc was very slow (it uses ETS).
> According to `ets:i().` the largest ETS table was:
>     49178           server_ssl_otp_session_cache ordered_set 5015080
> 305919839 ssl_manager
> We have worked around the problem by using lower session_lifetime.
> But reading the code I came to these questions:
>   - The cache is `ordered_set` type which has logarithmic access time.
> Does it have to be `ordered_set`, not just `set` (with constant access
> time)?
>   - There is no protection agains running multiple validators. This leads
> to many processes accessing single table and doing the same work. This
> seems to greatly increase SYS CPU usage and slowdown in other ETS tables.
> Should we skip new validator start if previous one is still running?
>   - ssl_session:valid_session is called for every session in cache and
> calls `calendar:datetime_to_gregorian_seconds({date(), time()})` itself.
> Should we use `erlang:monotonic_time(seconds)` everywhere instead? Or maybe
> we should pre-calculate minimal allowed timestamp to avoid extra
> arithmetics?
> --
> Danil Zagoskin | z@REDACTED
> _______________________________________________
> 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/20151209/a381252d/attachment.htm>

More information about the erlang-questions mailing list