<div dir="ltr"><br><div class="gmail_extra"><br></div><div class="gmail_extra">Hi,<br><br></div><div class="gmail_extra">I performed a series of test regarding the an Erlang SSL server.<br><br></div><div class="gmail_extra">In this setup a major role is played by the table called 'ssl_otp_session_cache', and of course the processes using it.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Some info about this:<br>$ erl -sname console@www-apps -remsh n1@www-apps -setcookie operator<br>Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false]<br><br>Eshell V6.2 (abort with ^G)<br><br><br>(n1@www-apps)1> ets:i().<br> id             name             type size  mem     owner<br> ----------------------------------------------------------------------------<br> 12             cookies          set  0     291     auth<br> 4111           code             set  410   26132   code_server<br> 8208           code_names       set  58    7459    code_server<br> 12307          httpc_manager__session_cookie_db bag  0     291     httpc_manager<br> 16404          ssl_otp_cacertificate_db set  0     291     ssl_manager<br> 20501          ssl_otp_ca_file_ref set  0     291     ssl_manager<br> 24598          ssl_otp_pem_cache set  3     360     ssl_manager<br><u><b> 28695          ssl_otp_session_cache ordered_set 138057 8421893 ssl_manager</b></u><br> 32797          dets             duplicate_bag 2     308     dets<br> 40990          ign_requests     set  0     291     inet_gethost_native<br> 45087          ign_req_index    set  0     291     inet_gethost_native<br> 2261635104     shell_records    ordered_set 0     81      <0.30638.37><br> ac_tab         ac_tab           set  33    2216    application_controller<br> code_map       code_map         set  100   2791    <0.72.0><br> config         config           set  12    892     <0.72.0><br> dets_owners    dets_owners      set  1     298     dets<br> dets_registry  dets_registry    set  1     299     dets<br> file_io_servers file_io_servers  set  1     344     file_server_2<br> global_locks   global_locks     set  0     291     global_name_server<br> global_names   global_names     set  0     291     global_name_server<br> global_names_ext global_names_ext set  0     291     global_name_server<br> global_pid_ids global_pid_ids   bag  0     291     global_name_server<br> global_pid_names global_pid_names bag  0     291     global_name_server<br> httpc_manager__handler_db httpc_manager__handler_db set  0     291     httpc_manager<br> httpc_manager__session_db httpc_manager__session_db set  0     291     httpc_manager<br> inet_cache     inet_cache       bag  0     291     inet_db<br> inet_db        inet_db          set  29    600     inet_db<br> inet_hosts_byaddr inet_hosts_byaddr bag  0     291     inet_db<br> inet_hosts_byname inet_hosts_byname bag  0     291     inet_db<br> inet_hosts_file_byaddr inet_hosts_file_byaddr bag  0     291     inet_db<br> inet_hosts_file_byname inet_hosts_file_byname bag  0     291     inet_db<br> models         models           set  3     28952   <0.72.0><br> sys_dist       sys_dist         set  1     334     net_kernel<br>ok<br>(n1@www-apps)5> ets:info(ssl_otp_session_cache).             <br>undefined<br>(n1@www-apps)7> (8421893*8)/1024.<br>65796.0390625<br>(n1@www-apps)8> memory().<br>[{total,92699464},<br> {processes,8964000},<br> {processes_used,8963152},<br> {system,83735464},<br> {atom,429569},<br> {atom_used,421768},<br> {binary,199040},<br> {code,10411520},<br> {ets,69163032}]<br><br></div><div class="gmail_extra">The memory allocated to table 'ssl_otp_session_cache' is roughly 64 MB in 12 hours.<br><br></div><div class="gmail_extra">On an OpenBSD platform such process gets killed immediately it hits some memory and/or CPU limits.<br><br></div><div class="gmail_extra">To make this test on OpenBSD I had to put 'infinit' to memory, otherwise the Erlang VM would be killed.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">How can one control , tweak or configure this table such that it does not accumulate such data at such high rate.<br><br></div><div class="gmail_extra">I seems the table being created private, and there is no way to ets:delete_all_objects/1 from table manually.<br><br></div><div class="gmail_extra">I know that this table caches some SSL data related to clients, but the client has the same IP address, <br>and I wonder why is neccesary to store a lot of SSL connection info about the same client when only the ephemeral peer port<br></div><div class="gmail_extra">differs?<br><br></div><div class="gmail_extra">How the size of this table can be held in reasonable limits and the rate it's size increases ?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Please if somebody shed some light on these issues.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you,<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Bogdan<br></div><div class="gmail_extra"><br><br></div></div>