[erlang-questions] UDP concurrent server

[Sergej Jurečko]

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/22f4dae1/attachment.htm>