<div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-09 18:02 GMT+01:00 Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Lucas!<div><br></div><div>I read the ssl 7.1 sources.</div><div><br><div>As for current maint:</div><div><div>Improved:</div><div> - <span style="font-size:12.8px">ssl_session:valid_session already uses the new time API: </span><a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_session.erl#L70" target="_blank">https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_session.erl#L70</a></div><div> - Max cache size is by default 1000 now: <a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L69" target="_blank">https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L69</a></div></div><div>Left as before:</div><div> - Cache table is still ordered_set: <a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_session_cache.erl#L36" target="_blank">https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_session_cache.erl#L36</a></div></div></div></blockquote><div><br></div><div>There is a reason for using orderd_set see: 35ffd19df295f5ff73f9968b65dc8ad957c943e5<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> - Multiple concurrent validators still possible: <a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L385" target="_blank">https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L385</a></div></div><div><br></div></div></blockquote><div><br></div><div>There will only be one validator instance started for the reason of hitting the threshold (max value), but you are correct that the poller validator assumes that the old one already should be gone. I will make a backlog item to make sure there is only one of those, in the meantime the other changes will hopefully makes this less of a problem. <br></div><div><br><br></div><div>Regards Ingela Erlang/OTP Team - Ericsson AB<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Limiting session cache size and using monotonic_time as timestamp should prevent our kind of problems.</div><div><br></div><div>Thank you!</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 3:39 PM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello!<div><br></div><div>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.</div><div><br></div><div>Lukas</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Dec 8, 2015 at 1:15 PM, Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr">Hi!<div><br></div><div>Recently our servers started to consume lots of SYS CPU.</div><div>Inside a VM top processes (by reductions per second) were ssl session validators.</div><div>Most popular current function in runnable processes was calendar:datetime_to_gregorian_seconds/2.</div><div>Also gproc was very slow (it uses ETS).<br></div><div><br></div><div>According to `ets:i().` the largest ETS table was:<br></div><div> 49178 server_ssl_otp_session_cache ordered_set 5015080 305919839 ssl_manager</div><div><br></div><div>We have worked around the problem by using lower session_lifetime.</div><div><br></div><div>But reading the code I came to these questions:</div><div> - 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)?</div><div> - 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?</div><div> - 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?</div><span><font color="#888888"><div><br></div><div><div><br></div>-- <br><div><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div></div></font></span></div>
<br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class=""><font color="#888888">-- <br><div><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div></div>