<div dir="ltr"><div><div>the same, although I 'd prefer not to touch the defaults.<br><br></div>entop output:<br>Node: '<a href="mailto:mps_dbg@10.10.13.104">mps_dbg@10.10.13.104</a>' (Disconnected) (18/7.0) unix (linux 4.0.4) CPU:2 SMP +A:10<br>Time: local time 15:14:15, up for 000:00:01:05, 0ms latency,<br>Processes: total 53 (RQ 0) at 12233 RpI using 4431.6k (4461.1k allocated)<br>Memory: Sys 239281.1k, Atom 189.8k/197.7k, <b>Bin 230708.1k,</b> Code 4828.6k, Ets 289.9k<br><br></div>1 minute about 220 MB<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 3:05 PM, Sergej Jurečko <span dir="ltr"><<a href="mailto:sergej.jurecko@gmail.com" target="_blank">sergej.jurecko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What if you run erlang with: <br><pre><code><span>-env</span><span> </span><span>ERL_FULLSWEEP_AFTER</span><span> </span><span>10</span></code></pre></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 2:02 PM, Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Seems a good idea but also a dangerous one.<br><br></div>I think I will stay with receiving {udp, Socket, Host, Port, Bin} messages<br></div><div>in controlling process and dispatch from there.<br><br></div><div>But now I face another problem...<br></div><div>I have :<br><br>handle_info({udp, Socket, Host, Port, Bin}, State)  -><br>    {noreply, State};<br></div><div><br><br></div><div>In a few minutes the memory allocated to binary increases to ~ 500MB<br></div><div>by running the command:<br><br>fmpeg -f lavfi -i aevalsrc="sin(40*2*PI*t)" -ar 8000 -f mulaw -f rtp rtp://<a href="http://10.10.13.104:5004" target="_blank">10.10.13.104:5004</a><br><br></div><div>It seems that the Bins are accumulated in the process memory area, an never are deallocated<br></div><div>unless the process is killed, which is not an option.<br><br></div><div>How can I manage this and to avoid running out of memory in a matter of minutes ?<br></div><div><br></div><div>If I change the clause to:<br>handle_info({udp1, Socket, Host, Port, Bin}, State) -><br><br></div><div>memory stays at 190KB.<br><br></div><div>So as long as the process receives the packet, this is accumulated in binary memory are<br></div><div>and never deallocated.<br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 2:23 PM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span><div dir="ltr">On Wed, Dec 9, 2015 at 1:11 PM Sergej Jurečko <<a href="mailto:sergej.jurecko@gmail.com" target="_blank">sergej.jurecko@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 9, 2015 at 12:59 PM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span></span><div>You can if you tell to the udp socket to reuse the port:</div><div><a href="https://github.com/refuge/rbeacon/blob/master/src/rbeacon.erl#L414-L425" target="_blank">https://github.com/refuge/rbeacon/blob/master/src/rbeacon.erl#L414-L425</a><br></div><div><br></div><div>If you do this any process will be able to reuse it and send/recv to it.</div><br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This enables you to call gen_udp:open for port X from multiple processes. Unfortunately as long as first socket is alive, all traffic will go there. So it's just a reliability improvement (if first process goes down), but not a scalability improvement.<br><br></div></div></div></div></blockquote><div><br></div></span><div>Well it would allows you to open different socket for the same ports for recv. Normally the threads should compete to get the data according to </div><div><br></div><div><a href="https://lwn.net/Articles/542629/" target="_blank">https://lwn.net/Articles/542629/</a></div><div><br></div><div>So until a process is on another thread or CPU it should increase the concurrency. <br></div><div><br></div><div>- benoît</div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>