<br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 1:06 AM, Jon Olav Vik <span dir="ltr">&lt;<a href="mailto:jonovik@gmail.com" target="_blank">jonovik@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">

Fernando Perez &lt;<a href="http://fperez.net" target="_blank">fperez.net</a> &lt;at&gt; <a href="http://gmail.com" target="_blank">gmail.com</a>&gt; writes:<br>
<div class="im"><br>
&gt; On Tue, Jun 19, 2012 at 12:39 AM, MinRK &lt;benjaminrk &lt;at&gt; <a href="http://gmail.com" target="_blank">gmail.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; This happens at the zeromq level - IPython has no way of controlling this.<br>
&gt;<br>
&gt; Question, what&#39;s the number of open fds per engine right now (plus any<br>
&gt; others opened by the hub)?<br>
<br>
</div>My guess is four per engine + some for the hub etc. Repeated tests yesterday<br>
gave me 240 engines from 10 nodes with 24 processors each, whereas the 11th<br>
seemed to break the controller&#39;s back, consistent with `ulimit -n` / 4 = 256.<br></blockquote><div><br></div><div>It is 3, but there are already quite a few already before any engines connect (~40).</div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
&gt; At least if we advertise what the formula<br>
&gt; is, users could tweak their job submission scripts to test their<br>
&gt; environment and only request a total number of engines that&#39;s safe<br>
&gt; given the constraints they find...<br>
<br>
</div>Googling around, I see that some batch schedulers have constraints on the<br>
number of concurrent CPUs per users, which would be a perfect fit here.<br></blockquote><div><br></div><div>That helps as long as you restrict yourself to one engine per CPU, which is generally totally up to the user.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(My problem is that my scheduled jobs quickly burn out when engines cannot<br>
connect, and I need to wait until some connections have died, then schedule<br>
more. I occurs to me now that I could perhaps have my main loop check len<br>
(c.ids) and release batch queue holds once there are vacancies.)<br>
<br>
<br>
A good workaround might be to have multiple ipclusters running:<br>
<br>
jsonfiles = [...]<br>
c = [Client(i) for i in jsonfiles]<br>
lv = [i.load_balanced_view() for i in c]<br>
<br>
def do(workpiece):<br>
    pass<br>
<br>
pdo = [i.parallel(ordered=False, retries=10)(do) for i in lv]<br>
<br>
# Insert clever coordination of multiple clusters here...<br>
# Simple example:<br>
workpieces = ...<br>
workpieces = np.array_split(workpieces, len(c))<br>
async = [i.map(j) for i, j in zip(pdo, workpieces)]<br>
<br>
Engine nodes could spread across clusters according to their CPU number or<br>
something.<br></blockquote><div><br></div><div>Yes, this is the sensible approach.  I have in my mind a scaling model for the cluster where schedulers are sharded, and engines/clients are split across different collections of identical schedulers.  With the way zeromq works, this is actually super easy with one exception: The load-balanced scheduler which has state, and would presumably need to share that state with its clones somehow.  All of the other schedulers are totally stateless, and can be replicated without any issue.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
</div></div></blockquote></div><br>