<br><br><div class="gmail_quote">On Fri, Feb 3, 2012 at 13:18, Caius Howcroft <span dir="ltr">&lt;<a href="mailto:caius.howcroft@gmail.com">caius.howcroft@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi MinRK<br>
<br>
(sorry reopening an old thread)<br>
<br>
I saw on github you guys made some changes to ZMQStreams (<br>
<a href="https://github.com/ipython/ipython/issues/1304" target="_blank">https://github.com/ipython/ipython/issues/1304</a> ) to try fix these<br>
heartbeat issues so I thought &quot;great&quot;, and installed the latest from<br>
github master branch.<br>
<br>
However, I&#39;m still seeing the exact same heartbeat warnings followed<br>
by the whole cluster coming down. I tried upping the Heartbeat.period<br>
to 10000 however this caused the cluster to never get going... see<br>
printout below.<br></blockquote><div><br></div><div>Unlike the two-process heartbeat used in the qtconsole and notebook, the parallel code does not consider an engine alive until it has responded to its first heartbeat.  That means setting a long heartbeat directly affects the amount of time it takes for an engine to become available (always greater than one heartbeat, and ~always less than two).</div>

<div><br></div><div>How long does it take your cluster to come down?  How many engines are you using? What sort of interconnect / env?  What Python, libzmq, and pyzmq versions?  How long do your individual tasks take?  How much data are you moving in your tasks?</div>

<div><br></div><div>I&#39;m perpetually baffled by this issue, because I&#39;ve been keeping clusters up for days on end, sending 100s of GB of data, and I&#39;ve never once seen this happen.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
<br>
2012-02-03 21:10:59.565 [IPClusterStart] Starting SSHEngineLauncher:<br>
[&#39;ssh&#39;, &#39;-tt&#39;, &#39;-o&#39;, &#39;StrictHostKeyChecking no&#39;,<br>
u&#39;ip-10-80-186-44.ec2.internal&#39;, &#39;/usr/bin/python&#39;,<br>
u&#39;/usr/local/lib/python2.7/dist-packages/ipython-0.12-py2.7.egg/IPython/parallel/apps/ipengineapp.py&#39;,<br>
&#39;--profile-dir&#39;, u&#39;/home/chowcroft/.ipython/profile_default&#39;,<br>
&#39;--log-level=20&#39;]<br>
2012-02-03 21:10:59.639 [IPClusterStart] Process &#39;ssh&#39; started: 6097<br>
2012-02-03 21:10:59.641 [IPClusterStart] Process &#39;engine set&#39; started:<br>
[None, None, None, None, None, None, None, None, None, None, None,<br>
None, None, None, None, None, None, None, None, None, None]<br>
2012-02-03 21:10:59.645 [IPClusterStart] Start the IPython controller<br>
for parallel computing.<br>
2012-02-03 21:10:59.646 [IPClusterStart] Connection to<br>
ip-10-114-41-115.ec2.internal closed.<br>
2012-02-03 21:10:59.646 [IPClusterStart] Process &#39;ssh&#39; stopped:<br>
{&#39;pid&#39;: 6042, &#39;exit_code&#39;: 1}<br>
2012-02-03 21:10:59.646 [IPClusterStart] IPython cluster: stopping<br>
<br>
<br>
Not quite sure what to do... it there something else that&#39;s timing out?<br></blockquote><div><br></div><div>The first step when debugging process startup is always to stop using ipcluster, and try to replicate what ipcluster does (call ipcontroller once, and ipengine 0-many times) with `--debug` flags.  IPCluster itself is a terrific pain to debug.</div>

<div> </div><div>-MinRK</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Many thanks<br>
<span class="HOEnZb"><font color="#888888"><br>
Caius<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Jan 11, 2012 at 5:54 PM, MinRK &lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Jan 11, 2012 at 10:59, Caius Howcroft &lt;<a href="mailto:caius.howcroft@gmail.com">caius.howcroft@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi everyone<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m running 0.12 on a linux cluster here and generally it has been<br>
&gt;&gt; great. However, some users are complaining that their jobs crash<br>
&gt;&gt; periodically with messages like this:<br>
&gt;&gt; [IPClusterStart] [IPControllerApp] heartbeat::got bad heartbeat<br>
&gt;&gt; (possibly old?): 1326305300.61 (current=1326305302.613)<br>
&gt;&gt; [IPClusterStart] [IPControllerApp] heartbeat::heart<br>
&gt;&gt; &#39;8f9428e4-543f-4218-b7b3-b32d57caa496&#39; missed a beat, and took 1961.06<br>
&gt;&gt; ms to respond<br>
&gt;&gt; [IPClusterStart] [IPControllerApp] heartbeat::ignoring new heart:<br>
&gt;&gt; &#39;8f9428e4-543f-4218-b7b3-b32d57caa496&#39;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Generally this brings everything to halt. So my question is two fold:<br>
&gt;&gt; Firstly, I&#39;m pretty sure my machines are synced up well, so I dont<br>
&gt;&gt; think its anything I&#39;m doing. Has anyone had this same problem?<br>
&gt;<br>
&gt;<br>
&gt; I have never seen this myself, but I have heard of it from one other<br>
&gt; user. It is very hard to debug, as it often takes many hours to reproduce.<br>
&gt;  When this happens, an engine is treated as dead, even though it actually<br>
&gt; isn&#39;t.  One option is to increase the heartbeat timeout to something more<br>
&gt; like ten or thirty seconds (HeartbeatMonitor.period = 10000).  Note that<br>
&gt; this directly affects the amount of time it takes for the new engine<br>
&gt; registration process, because an engine is not deemed to be ready until its<br>
&gt; heart has started beating.<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Secondly, clearly at some point somewhere a machine is going to belly<br>
&gt;&gt; up and I want to make the processing robust to that. How do I<br>
&gt;&gt; configure LoadBalancedView to notice that a machine has gone bad and<br>
&gt;&gt; reassign jobs that were assigned to that machine? I notice that when<br>
&gt;&gt; we launch a set of jobs, they all get assigned to engines immediately,<br>
&gt;&gt; cI think I can change this by changing . c.TaskScheduler.hwm=1<br>
&gt;<br>
&gt;<br>
&gt; Yes, hwm=1 prevents any greedy scheduling of tasks at the expense of hiding<br>
&gt; network latency behind computation time, and increasing load on the<br>
&gt; scheduler.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; , but<br>
&gt;&gt; how do I tell the task manager to reconfigure the load if a node goes<br>
&gt;&gt; bad or a job fails.<br>
&gt;<br>
&gt;<br>
&gt; Tasks can be resubmitted (explicitly requested from the client) or retried<br>
&gt; (handled inside the scheduler).<br>
&gt; If the most likely cause of a task failure is not<br>
&gt; that the task itself has a bug, then you can set `retries=1` or even 5 in<br>
&gt; the unlikely<br>
&gt; event that it gets run on multiple engines that go down.  retries should not<br>
&gt; be greater than the number of engines you have, because a task will *not* be<br>
&gt; resubmitted to an engine where it failed.<br>
&gt;<br>
&gt; You can set the default value for retries submitted with a given view:<br>
&gt;<br>
&gt; lbview.retries = 5<br>
&gt;<br>
&gt; Or you can set it for a single block with temp_flags:<br>
&gt;<br>
&gt; with lbview.temp_flags(retries=5):<br>
&gt;     lbview.apply(retrying_task)<br>
&gt;<br>
&gt; One should be careful with this, because you can actually bring down your<br>
&gt; entire cluster by retrying<br>
&gt; a segfaulting task too many times:<br>
&gt;<br>
&gt; def segfault():<br>
&gt;     &quot;&quot;&quot;This will crash a linux system; equivalent calls can be made on<br>
&gt; Windows or Mac&quot;&quot;&quot;<br>
&gt;     from ctypes import CDLL<br>
&gt;     libc = CDLL(&quot;libc.so.6&quot;)<br>
&gt;     libc.time(-1)  # BOOM!!<br>
&gt;<br>
&gt; with lbview.temp_flags(retries=len(lbview.client.ids)):<br>
&gt;     lbview.apply(segfault)<br>
&gt;<br>
&gt; -MinRK<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Cheers<br>
&gt;&gt;<br>
&gt;&gt; Caius<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; IPython-User mailing list<br>
&gt;&gt; <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>