[erlang-questions] Where the Erlang node tick response will get stored ?.
Ulf Wiger
ulf@REDACTED
Wed Jun 7 17:43:48 CEST 2017
Yes?
This is in line with Erlang's design philosophy, and the processes are
small. This is from a node I just fired up:
Eshell V7.3.1 (abort with ^G)
(a@REDACTED)1> net:ping('b@REDACTED').
pong
(a@REDACTED)2> i().
Pid Initial Call Heap Reds
Msgs
Registered Current Function Stack
...
<0.43.0> inet_tcp_dist:do_setup/7 376 1043
0
dist_util:con_loop/9 11
(a@REDACTED)3> i(0,43,0).
[{current_function,{dist_util,con_loop,9}},
...,
{total_heap_size,752},
{heap_size,376},
{stack_size,11},
{reductions,1085},
...]
(Sizes are in heap words - 8 bytes on my machine, so ca 6K bytes total heap
size.)
You can easily verify that connecting additional nodes will cause
additional con_loop() processes to be started, one per connected node.
The size of these processes can be expected to stay pretty much constant.
BR,
Ulf W
2017-06-07 8:17 GMT+01:00 lankeanandrao <lankeanandrao@REDACTED>:
> Hi Ulf,
> Here you are saying that there will be separate con_loop for 1:1 node
> connection, is it means that how many client nodes are connected to server
> node those many instances of con_loop will run in server.
>
> Example :
> server@REDACTED and multiple clients client1@REDACTED, client2@REDACTED ...
> ClientN@REDACTED all are in cluster and all client nodes are connected to
> server, now in server to connect
> server@REDACTED to client1@REDACTED - 1st con_loop
> server@REDACTED to client2@REDACTED - 2nd con_loop
> server@REDACTED to clientN@REDACTED - nth con_loop
> multiple con_loops will run in server for connecting to each client
> node.
>
> Thanks & Regards,
> Anand Rao L
>
> On Tuesday 06 June 2017 09:40 PM, Ulf Wiger wrote:
>
> The tick message is received in dist_util:con_loop/2:
>
> https://github.com/erlang/otp/blob/master/lib/kernel/src/
> dist_util.erl#L486
>
> There is a con_loop for each 1:1 node connection, and the tick state
> simply keeps track of the number of tick intervals for which no data has
> been received on the connection (note that at least ticks should have been
> received.)
>
> Based on experience, with such a short ticktime, you might want to pay
> attention to the +zdbbl setting for erl (dist_buf_busy_limit). If it is set
> too low, there is a risk that the ticker process is suspended and the
> connection times out. I believe this is less of a problem than it used to
> be, when the distribution buffer busy limit was much lower (and not
> configurable.)
>
> BR,
> Ulf W
>
> 2017-06-06 7:15 GMT+01:00 lankeanandrao <lankeanandrao@REDACTED>:
>
>> Hi all,
>>
>> I am running my application in a distributed way, with one server
>> node and multiple client nodes and all nodes are started in visible mode.
>> Here I want to know when all the client nodes are connected to the server
>> node, the client nodes will send the tick message to server node and as
>> same as the server will send tick message to all client nodes, here all the
>> client nodes send tick response to the server node. So here my question is
>>
>> 1. Where the tick response came from multiple client nodes is getting
>> stored?
>>
>> 2. If it is getting stored in kernel buffer, what is the buffer size
>> and how to find that?
>>
>> 3. How the tick response's of multiple nodes is getting served by the
>> Erlang kernel?
>>
>> Note: The net tick time is set to 5 Second in all the nodes.
>>
>> Thanks & Regards,
>> Anand Rao L
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170607/0e45de68/attachment.htm>
More information about the erlang-questions
mailing list