<div dir="ltr">Hi,<div><br></div><div>It's just a guess, but maybe the rex processes (the servers accepting rpc calls) get blocked for a long time or get into some deadlock situation following the node crash. This would explain why can't you open a new remote shell: that request too goes via rpc.</div><div><br></div><div>Try using spawn/4 to start a process on one of the inaccessible nodes or do raw gen_server:call-s using {Name, Node}, because these requests don't have to go through the rex server. Maybe you can debug the problem with these tools. Or, if these techniques would not work, you can be sure that the problem is somewhere deep within erts...</div><div><br></div><div>Cheers,</div><div>Daniel</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 13 Jul 2017 at 21:43 Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Very little to go by.<div><br></div><div>My recommendation would be to analyze bottom up through the layers if possible. Telemetry of IO is useful. The Erlang VM tracks this. Telemetry of port and process count as well. A sharp drop in CPU load would suggest processes are blocked on something and waiting for stuff to happen. By working from the network and up, you can often gain valuable information which can be used to rule out hypothesis underway.</div><div><br></div><div>What does your logger say about the situation? Anything odd in those logs? Do you run with system_monitor enabled and does it mention something? Crash logs? Do you run with exometer_core or something such in the cluster (you should! establish a baseline of typical operation so you know when things look weird. You really want measurement on the critical paths, at least sampling. Otherwise you have no chance at scaling the load over time). What does the kernel say about TCP send queues on the distribution channels? Are the TCP windows there closed or open?</div><div><br></div><div>The usual way is to form some kind of hypothesis. Then devise a method to either confirm or reject the hypothesis. Then form a new one and so on. Write down everything you find in a document which is shared among investigators (Git or Google Docs, etc). Track knowledge. One thing which is very important to look out for are assumptions. If you have an assumption, you should figure out a way to determine if it is true or not. You are most often lead astray by an incorrect assumption somewhere in the chain of events. And this has you hunting for a problem in a corner of the system where no problems occur.</div><div><br></div><div>Other haphazard list of stuff:</div><div><br></div><div>- any nasty NIFs?</div><div>- dTrace on the boxes? (Godsend when things go wrong)</div><div>- Consider establishing an Erlang shell early if it is a resource problem. Then one is handy when things start going wrong.</div><div>- Can you provoke the error in a smaller test cluster? Possibly be artificially resource constraining its network devices as well?</div><div>- If you can't create a shell, something rather central could be hosed. Try figuring out if you ran out of resources etc.</div><div>- A slow disk coupled with synchronous calls can easily block a machine</div><div>- Excessive debug logging too, but that would max out the CPU load</div><div>- The problem might not even be in Erlang. Everything from faulty hardware, faulty kernel, bad cloud provider, to Elixir or LFE might be the culprit. Narrowing down the list of likely candidates is important.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 13, 2017 at 7:58 PM Juan Jose Comellas <<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Steve, is it possible that the processes were trying to contact other processes on the node that went down and were blocking in responses from them? If so, do you have timeouts in the calls you make to those processes. Also, are you referencing the remote processes in the node that went down by pid or by global name?<div><br></div><div>As Lukas said, it's difficult to know what happened without more information, but the answers to the questions above might shed some light on the cause(s) of the problem.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 13, 2017 at 2:26 PM, Steve Cohen <span dir="ltr"><<a href="mailto:scohen@discordapp.com" target="_blank">scohen@discordapp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Lukas,<div>The second situation is more representative of what happened; CPU quickly trended towards zero, and the VMs were unresponsive. The situation was stable, and didn't generate an erl_crash.dump or a core dump. Next time this happens, we'll try to trigger one.  </div><div><br></div><div>Since we couldn't get into the VMs, all we have to go on is telemetry, which isn't as accurate as being in the remote console. If it helps, I'd be glad to share our telemetry data. The entire cluster immediately experienced a drop in CPU. It was quite strange.</div><div><br></div><div>Agreed about the remote shell, I guess without a dump, we're stuck.</div><div><br></div></div><div class="gmail_extra"><div><div class="m_8180802976370206985m_-704043909257436038h5"><br><div class="gmail_quote">On Thu, Jul 13, 2017 at 12:12 AM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Steve,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Jul 10, 2017 at 4:14 PM, Steve Cohen <span dir="ltr"><<a href="mailto:scohen@discordapp.com" target="_blank">scohen@discordapp.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="background-color:rgb(255,255,255)"><font color="#000000">Now, when one of our guild servers dies, as expected it generates a large number of DOWN messages to the sessions cluster. These messages bog down the sessions servers (obviously) while they process them, but when they're done processing, distribution appears to be completely broken. </font></span><div dir="ltr"><br></div></blockquote><div><br></div></span><span><div>On Thu, Jul 13, 2017 at 1:10 AM, Steve Cohen <span dir="ltr"><<a href="mailto:scohen@discordapp.com" target="_blank">scohen@discordapp.com</a>></span> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Here's the sequence of events:</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1. One of our machines was inadvertently shut off, killing all of the processes on it</div><div>2. We immediately saw a drop in CPU across the board on the sessions cluster. CPU on the sessions cluster eventually went to zero.</div><div>3. We were completely unable to use remote console on any of the machines in the cluster, and they all needed to be restarted.</div></div></blockquote><div><br></div></span><div>The two scenarios you are describing seem to contradict each other? First you talk about the sessions servers being bogged down, and then that the CPU of the sessions cluster went to almost zero? What is it that I'm missing?</div><div><br></div><div>Did you gather any port mortem dumps from these machines? i.e. a erl_crash.dump or a core dump?</div><div><br></div><div>Also you have forgotten to mention what version of Erlang/OTP that you are using.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>So, to answer your question, we don't know how long it took for down messages to be processed, since we didn't have visibility at the time.  We suspected a problem with the net_ticktime, but what's confusing to us is that the host that went down went down hard, so the DOWN events should have been created on the other nodes, not sent across distribution (correct me if I'm wrong here).<br></div></div></blockquote><div><br></div></span><div>When a TCP connection used for the erlang distribution is terminated, all the down messages are (as you say) generated locally. </div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Also, my intuition is that processing DOWN messages would cause CPU usage on the cluster to go up, but we saw the exact opposite.  </div><div><br></div></div></blockquote><div><br></div></span><div>With the poweroff of the machine, are you sure that the TCP layer caught the shutdown? If it didn't, then the next fail-safe is the net_ticktime.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Since we couldn't connect to the machines via remote console, we couldn't call connect_node. It was my understanding that the connect call would happen when the node in question reestablished itself. </div></div></blockquote><div><br></div></span><div>Yes, it should re-connect when needed. It is quite strange that you couldn't connect via remote shell. A crash dump or core dump would really help to understand what is going on.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div></div><div class="gmail_extra"><div><div class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-h5"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 8:34 PM, Juan Jose Comellas <span dir="ltr"><<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">How long does it take for all the DOWN messages to be sent/processed?<div><br></div><div>These messages might not be allowing the net tick messages (see <font face="monospace, monospace">net_ticktime</font> in <a href="http://erlang.org/doc/man/kernel_app.html" target="_blank">http://erlang.org/doc/man/kernel_app.html</a>) to be responded in time. If this happens, the node that isn't able to respond before the <font face="monospace, monospace">net_ticktime</font> expires will be assumed to be disconnected.</div><div><br></div><div>What happens if after processing all the DOWN messages you issue a call to <font face="monospace, monospace">net_kernel:connect_node/1</font> for each of the nodes that seems to be down?</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-m_6012173522151130881h5">On Mon, Jul 10, 2017 at 4:14 PM, Steve Cohen <span dir="ltr"><<a href="mailto:scohen@discordapp.com" target="_blank">scohen@discordapp.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-m_6012173522151130881h5"><div dir="ltr">Hi all,<div><br></div><div>We have 12 nodes in a our guilds cluster, and on each, 500,000 processes.  We have another cluster that has 15 nodes with roughly four million processes on it, called sessions. Both clusters are in the same erlang distribution since our guilds monitor sessions and vice-versa.</div><div><br></div><div>Now, when one of our guild servers dies, as expected it generates a large number of DOWN messages to the sessions cluster. These messages bog down the sessions servers (obviously) while they process them, but when they're done processing, distribution appears to be completely broken. </div><div> <br clear="all"><div>By broken, I mean that the nodes are disconnected from one another, they're not exchanging messages, CPU usage was 0 and we couldn't even launch the remote console. </div><div><br></div><div>I can't imagine this is expected behavior, and was wondering if someone can shed some light on it.</div><div>We're open to the idea that we're doing something very, very wrong.</div><div><br></div><div><br></div><div>Thanks in advance for the help</div><span class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-m_6012173522151130881m_-2169475019866148019HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-m_6012173522151130881m_-2169475019866148019m_7580302084062849632gmail_signature"><div dir="ltr">Steve Cohen</div></div>
</font></span></div></div>
<br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-HOEnZb"><font color="#888888">-- <br><div class="m_8180802976370206985m_-704043909257436038m_6483419527883423862m_4242710364008575055gmail-m_6012173522151130881gmail_signature"><div dir="ltr">-Steve</div></div>
</font></span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></span></div><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_8180802976370206985m_-704043909257436038HOEnZb"><font color="#888888">-- <br><div class="m_8180802976370206985m_-704043909257436038m_6483419527883423862gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Steve</div></div>
</font></span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>