[erlang-questions] UDP concurrent server

[Bogdan Andu]

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/0ec2311c/attachment.htm>