<div dir="ltr">We have a productive system where one Erlang node connected to another node<br>performs badly when the second node is down. In such a case the message queues on<br>the first node augment and the node does not manage to process its messages<br>quickly enough. The communication between the nodes is done with GenServer.cast.<br>When sending a message to the second node from the first node we use a call similar to<br>GenServer.cast({:registered_name_on_the_remote, "<a href="mailto:nodeid@server2.example.com">nodeid@server2.example.com</a>"}, msg).<br><br>With tcpdump, traces, trial and errors and reading some of the Erlang code, I<br>have identified that the :inet_gethost_native.gethostbyname is invoked a huge<br>number of times as long as the second down is stopped. This increase in load<br>causes the function to sometimes take more than 3 seconds before returning a<br>value! With tcpdump I have measured how long the DNS queries take and can confirm<br>that this increase in time is due to the Erlang code and not to the network or<br>dns server (max time for a DNS query is 15ms).<br><br>I have created a proof of concept with a detailed README showing how to reproduce the problem:<br><a href="https://www.github.com/pallix/erlang_dns_under_stress">https://www.github.com/pallix/erlang_dns_under_stress</a><br><br>It creates much more IO and less CPU load than our production problem but the<br>external behavior is similar: when the second node is restarted, the DNS resolution is<br>fast again. My knowledge of Erlang is limited so the code is in Elixir but simple enough that everybody knowing Erlang should be able to reproduce the problem in Erlang.<br><br>My team and I are surprised that such a situation put Erlang under stress and that just disconnecting/stopping (with Ctrl-C or systemctl stop <service>) the node causes this problem. After all, a node being down should not be a big deal and DNS queries should be<br>cached.<br><br>We used Erlang 21, Elixir 1.10 and Debian Stretch when we discovered the<br>problem. We have know updated to Erlang 23, Elixir 1.11 and Debian Buster and<br>the problem persists.<br><br>Would you consider this behavior a bug?<br><br>Do you have experience with such a situation?<br><br><div>I have posted a similar message on the elixir forum a few days ago but did not get any answer so I think it's appropriate to ask here, some experts may have more knowledge of the BEAM internals.</div><div><br></div><div>Any help will be highly appreciated. </div></div>