<div dir="ltr"><div><div><div><div><div>Update to my previous email:<br><br></div><div>Doing some tests gave in the following conclusion: <br></div><div><br></div>in Erlang/OTP 17 [erts-6.3] the leaks does not appear at all:<br></div>entop output:<br>Node: '<a href="mailto:mps_dbg@192.168.0.5">mps_dbg@192.168.0.5</a>' (Disconnected) (17/6.3) unix (linux 4.2.6) CPU:2 SMP +A:10<br>Time: local time 19:21:51, up for 000:00:02:45, 0ms latency,<br>Processes: total 53 (RQ 0) at 159238 RpI using 4516.0k (4541.4k allocated)<br>Memory: Sys 8348.8k, Atom 190.9k/197.7k, Bin 134.3k, Code 4737.9k, Ets 285.7k<br><br></div>It is Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false]<br><br></div>where the leaks happens. In 2 minutes I would have about 220 MB of binaries.<br><br></div><div>So may be in OTP 18 is something changed that needs to be taken into account?<br></div><div><br></div>More long running test must be done for better conclusions<br><div><br><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 6:13 PM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</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"><span class="">On 12/09, Bogdan Andu wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
init([Port, Ip]) -><br>
       process_flag(trap_exit, true),<br>
<br>
       {ok, Sock} = gen_udp:open(Port, [binary,<br>
                           {active, false},<br>
                            {reuseaddr, true},<br>
                           {ip, Ip}<br>
       ]),<br>
<br>
       {ok, #udp_conn_state{sock = Sock}, 0}.<br></span><span class="">
handle_info({udp, Socket, Host, Port, Bin}, State) -><br>
    {noreply, State, 1};<br>
<br>
handle_info(timeout, #udp_conn_state{sock = Sock} = State) -><br>
   inet:setopts(Sock, [{active, once}]),<br>
   {noreply, State};<br>
<br>
handle_info(Info, State) -><br>
   {noreply, State}.<br>
<br>
</span></blockquote>
<br>
</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Uh, interesting. So one thing I'd change early would be to go:<br>
<br>
   handle_info({udp, Socket, Host, Port, Bin}, State=#udp_conn_state{sock = Sock}) -><br>
       inet:setopts(Sock, [{active,once}]),<br>
       {noreply, State};<br>
<br>
(and do the same in `init/1')<br>
<br></blockquote><div>@ Fred: yes you are right, is cleaner and faster that way. <br></div><div>But initially I wanted a separation of these.<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">
This at least would let yo consume information much faster by avoiding manual 1 ms sleeps everywhere. Even a `0' value may help. It doesn't explain the leaking at all though.<br>
<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What would explain it is that if you're not matching the message (as in your original email), then you never set the socket to 'active' again, and you never receive traffic.<br>
<br></blockquote><div> Not matching the message caused no leaks<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">
If that's the problem, then you have been measuring a process that receives traffic to a process that does not. It certainly would explain the bad behaviour you've seen.<br>
<br>
If you want to try to see if a garbage collection would help, you can try the 'recon' library and call 'recon:bin_leak(10)' and it will take a snapshot, run a GC on all processes, then return you those that lost the most memory. If yours is in there, then adding 'hibernate' calls from time to time (say, every 10,000 packets) could help keep things clean.<br>
<br>
It sucks, but that might be what is needed if the shape of your data is not amenable to clean GCs. If that doesn't solve it, then we get far funner problems with memory allocation.<br>
<br>
</blockquote></div><br></div></div></div>