<div>On Thu, Aug 30, 2012 at 3:06 PM, Constantine Evans <span dir="ltr">&lt;<a href="mailto:cevans@evanslabs.org" target="_blank">cevans@evanslabs.org</a>&gt;</span> wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello everyone,<br>
<br>
I&#39;m currently having some difficulty with ipcontroller seeming to<br>
choke when given too many tasks on too large a cluster, and was<br>
wondering whether anyone else had experienced this.<br>
<br>
I&#39;m using a cluster with the following configuration:<br>
* ipcontroller running on one machine, with 7 ipengines<br>
* ipengines running on 19 other machines with between 2 and 8<br>
instances per machine (1 per core), all connecting to ipcontroller via<br>
ssh. There are 72 ipengines in total.<br>
* the client running on my laptop and connected via ssh. My laptop is<br>
also one of the 19 machines<br>
<br>
On this setup, giving 1600 tasks seemed to work relatively well.<br>
<br>
However, giving it 16000 of the same tasks doesn&#39;t seem to be working.<br>
With perhaps only a few hundred tasks completed, queue_status() is<br>
only telling me about 4500 tasks unassigned at this point, at least<br>
twenty minutes after starting. Tasks are completing very slowly, and<br>
most of the ipengines seem to be idle.<br>
<br>
The only thing using significant CPU is ipcontroller, which is taking<br>
up 100% of its core. It doesn&#39;t seem to be using significant memory,<br>
however (&lt;300MB).<br>
<br>
Has anyone else run into limitations like these? Is there some way<br>
around them? Do I simply have a bad configuration, or is there<br>
something more fundamental that might be wrong here?<br></blockquote><div><br></div><div>Unfortunately it can be any or all of the above.</div><div><br></div><div>A few questions:<div><br></div><div>1. IPython version (git hash if tracking git)</div>

<div>2. HubFactory.db_class, if specified</div><div>3. TaskScheduler.hwm (assuming you are using load-balancing), if specified</div><div>4. What is the nature of your tasks (data arguments / return values, relationship between tasks, characteristic time, etc.)?</div>

<div><br></div><div>Due to the use of multiprocessing, the Hub and all Schedulers will identify themselves as &#39;ipcontroller&#39;, if you look at all of these processes ordered by PID, can you tell which one is using 100% CPU?</div>

<div><br></div><div>If it&#39;s not the first, then it&#39;s likely the task scheduler choking on the long queue.</div><div><br></div><div>Two options might help alleviating this:</div><div><br></div><div>1. increase TaskScheduler.hwm to something like 100 (that&#39;s the number of tasks that are allowed to be assigned to a given task), or you can try it with `0`, which means that tasks will be greedily assigned to engines as fast as possible.</div>

<div>2. Depending on what features you use, you might try using the pure zmq scheduler with:</div><div><br></div><div>    TaskScheduler.scheme_name = &#39;pure&#39;</div><div><br></div><div>The pure zmq scheduler does not support any of the advanced features of the Python scheduler (fault tolerance, retries, dependencies, etc.), but it is extremely lightweight.</div>

</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Constantine Evans<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>
</blockquote></div><br></div>