[erlang-questions] UDP concurrent server

[Benoit Chesneau]

@Bogdan you can use binary:copy  to reduce the memory usage in your case.
It all depends on your code I guess.

- benoit


On Wed, Dec 9, 2015 at 2:16 PM Bogdan Andu <bog495@REDACTED> wrote:

> the same, although I 'd prefer not to touch the defaults.
>
> entop output:
> Node: 'mps_dbg@REDACTED' (Disconnected) (18/7.0) unix (linux 4.0.4)
> CPU:2 SMP +A:10
> Time: local time 15:14:15, up for 000:00:01:05, 0ms latency,
> Processes: total 53 (RQ 0) at 12233 RpI using 4431.6k (4461.1k allocated)
> Memory: Sys 239281.1k, Atom 189.8k/197.7k, *Bin 230708.1k,* Code 4828.6k,
> Ets 289.9k
>
> 1 minute about 220 MB
>
>
> On Wed, Dec 9, 2015 at 3:05 PM, Sergej Jurečko <sergej.jurecko@REDACTED>
> wrote:
>
>> What if you run erlang with:
>>
>> -env ERL_FULLSWEEP_AFTER 10
>>
>>
>> On Wed, Dec 9, 2015 at 2:02 PM, Bogdan Andu <bog495@REDACTED> wrote:
>>
>>> Seems a good idea but also a dangerous one.
>>>
>>> I think I will stay with receiving {udp, Socket, Host, Port, Bin}
>>> messages
>>> in controlling process and dispatch from there.
>>>
>>> But now I face another problem...
>>> I have :
>>>
>>> handle_info({udp, Socket, Host, Port, Bin}, State)  ->
>>>     {noreply, State};
>>>
>>>
>>> In a few minutes the memory allocated to binary increases to ~ 500MB
>>> by running the command:
>>>
>>> fmpeg -f lavfi -i aevalsrc="sin(40*2*PI*t)" -ar 8000 -f mulaw -f rtp
>>> rtp://10.10.13.104:5004
>>>
>>> It seems that the Bins are accumulated in the process memory area, an
>>> never are deallocated
>>> unless the process is killed, which is not an option.
>>>
>>> How can I manage this and to avoid running out of memory in a matter of
>>> minutes ?
>>>
>>> If I change the clause to:
>>> handle_info({udp1, Socket, Host, Port, Bin}, State) ->
>>>
>>> memory stays at 190KB.
>>>
>>> So as long as the process receives the packet, this is accumulated in
>>> binary memory are
>>> and never deallocated.
>>>
>>> On Wed, Dec 9, 2015 at 2:23 PM, Benoit Chesneau <bchesneau@REDACTED>
>>> wrote:
>>>
>>>>
>>>> On Wed, Dec 9, 2015 at 1:11 PM Sergej Jurečko <sergej.jurecko@REDACTED>
>>>> wrote:
>>>>
>>>>> On Wed, Dec 9, 2015 at 12:59 PM, Benoit Chesneau <bchesneau@REDACTED>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> You can if you tell to the udp socket to reuse the port:
>>>>>>
>>>>>> https://github.com/refuge/rbeacon/blob/master/src/rbeacon.erl#L414-L425
>>>>>>
>>>>>> If you do this any process will be able to reuse it and send/recv to
>>>>>> it.
>>>>>>
>>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>> 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
>>>>
>>>> https://lwn.net/Articles/542629/
>>>>
>>>> So until a process is on another thread or CPU it should increase the
>>>> concurrency.
>>>>
>>>> - benoît
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151209/b1efefef/attachment.htm>