[erlang-questions] 'ssl_otp_session_cache' ets table

[Bogdan Andu]

Hi,

I performed a series of test regarding the an Erlang SSL server.

In this setup a major role is played by the table called
'ssl_otp_session_cache', and of course the processes using it.

The problem is that the size of table increases constantly and, because an
ets table does not automatically deallocate memory unless the object are
deleted from that table, the size of table remains the same even if there
no ssl connections to server.

For example, with a single client running 'ad infinitum' the table
increases at a rate of 5 MBytes/hour. In 12 hours there are allocate around
60 MB of memory only for this table.

Some info about this:
$ erl -sname console@REDACTED -remsh n1@REDACTED -setcookie operator
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:2:2] [async-threads:10]
[kernel-poll:false]

Eshell V6.2  (abort with ^G)


(n1@REDACTED)1> ets:i().
 id              name              type  size   mem      owner
 ----------------------------------------------------------------------------
 12              cookies           set   0      291      auth
 4111            code              set   410    26132    code_server
 8208            code_names        set   58     7459     code_server
 12307           httpc_manager__session_cookie_db bag   0      291
httpc_manager
 16404           ssl_otp_cacertificate_db set   0      291      ssl_manager
 20501           ssl_otp_ca_file_ref set   0      291      ssl_manager
 24598           ssl_otp_pem_cache set   3      360      ssl_manager
* 28695           ssl_otp_session_cache ordered_set 138057 8421893
ssl_manager*
 32797           dets              duplicate_bag 2      308      dets
 40990           ign_requests      set   0      291      inet_gethost_native
 45087           ign_req_index     set   0      291      inet_gethost_native
 2261635104      shell_records     ordered_set 0      81       <0.30638.37>
 ac_tab          ac_tab            set   33     2216
application_controller
 code_map        code_map          set   100    2791     <0.72.0>
 config          config            set   12     892      <0.72.0>
 dets_owners     dets_owners       set   1      298      dets
 dets_registry   dets_registry     set   1      299      dets
 file_io_servers file_io_servers   set   1      344      file_server_2
 global_locks    global_locks      set   0      291      global_name_server
 global_names    global_names      set   0      291      global_name_server
 global_names_ext global_names_ext  set   0      291      global_name_server
 global_pid_ids  global_pid_ids    bag   0      291      global_name_server
 global_pid_names global_pid_names  bag   0      291      global_name_server
 httpc_manager__handler_db httpc_manager__handler_db set   0      291
httpc_manager
 httpc_manager__session_db httpc_manager__session_db set   0      291
httpc_manager
 inet_cache      inet_cache        bag   0      291      inet_db
 inet_db         inet_db           set   29     600      inet_db
 inet_hosts_byaddr inet_hosts_byaddr bag   0      291      inet_db
 inet_hosts_byname inet_hosts_byname bag   0      291      inet_db
 inet_hosts_file_byaddr inet_hosts_file_byaddr bag   0      291      inet_db
 inet_hosts_file_byname inet_hosts_file_byname bag   0      291      inet_db
 models          models            set   3      28952    <0.72.0>
 sys_dist        sys_dist          set   1      334      net_kernel
ok
(n1@REDACTED)5> ets:info(ssl_otp_session_cache).
undefined
(n1@REDACTED)7> (8421893*8)/1024.
65796.0390625
(n1@REDACTED)8> memory().
[{total,92699464},
 {processes,8964000},
 {processes_used,8963152},
 {system,83735464},
 {atom,429569},
 {atom_used,421768},
 {binary,199040},
 {code,10411520},
 {ets,69163032}]

The memory allocated to table 'ssl_otp_session_cache' is roughly 64 MB in
12 hours.

On an OpenBSD platform such process gets killed immediately it hits some
memory and/or CPU limits.

To make this test on OpenBSD I had to put 'infinit' to memory, otherwise
the Erlang VM would be killed.

How can one control , tweak or configure this table such that it does not
accumulate such data at such high rate.

I seems the table being created private, and there is no way to
ets:delete_all_objects/1 from table manually.

I know that this table caches some SSL data related to clients, but the
client has the same IP address,
and I wonder why is neccesary to store a lot of SSL connection info about
the same client when only the ephemeral peer port
differs?

How the size of this table can be held in reasonable limits and the rate
it's size increases ?

Please if somebody shed some light on these issues.

Thank you,

Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141105/533bad44/attachment.htm>