[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