<div dir="auto">Moving today, so I'll be brief.<div dir="auto"><br></div><div dir="auto">This sounds like the memory problems we've had on rack 4. There, there are just too many cures for the amount of memory, so if too many runs start, none get enough memory. That's why rack 4 isn't on the Tom or big go service tags. Probably means we should remove rack 0 from those tags for now until we figure it out.</div><div dir="auto"><br></div><div dir="auto">I've done runs on rack 4 by limiting each run to 1GB of memory.</div><div dir="auto"><br></div><div dir="auto">Tom</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jul 19, 2017 7:46 AM, "Lee Spector" <<a href="mailto:lspector@hampshire.edu">lspector@hampshire.edu</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I launched some runs this morning (a couple of hours ago -- I'm in Europe) that behaved oddly. I don't know if this is related to recent upgrades/reconfiguration, or what, but I thought I'd share them here.<br>
<br>
First, there were weird delays between launches and the generation of the initial output. I'm accustomed to delays of a couple of minutes at this point, which I think we've determined (or just guessed) are due to the necessity of re-downloading dependencies on fly nodes, which doesn't occur when running on other machines. But these took much longer, maybe 30-45 minutes or longer (not sure of the exact times, but they were on that order). And weirder still, there were long times during which many had launched but only one was producing output and proceeding for a long time, with others really kicking in only after the early one(s) finished. I'd understand this if the non-producing ones weren't launched at all, because they were waiting for free slots.... but that's not what was happening.<br>
<br>
And then one crashed, on compute-0-1 (this was launched with the "tom" service tag, using the run-fly script in Clojush), with nothing in the .err file (from standard error) but the following in the .out file (from standard output):<br>
<br>
Producing offspring...<br>
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(<wbr>0x00000006f0e00000, 1059061760, 0) failed; error='Cannot allocate memory' (errno=12)<br>
#<br>
# There is insufficient memory for the Java Runtime Environment to continue.<br>
# Native memory allocation (malloc) failed to allocate 1059061760 bytes for committing reserved memory.<br>
# An error report file with more information is saved as:<br>
# /home/lspector/runs/july19a-<wbr>9235/Clojush/hs_err_pid57996.<wbr>log<br>
<br>
 -Lee<br>
<br>
--<br>
Lee Spector, Professor of Computer Science<br>
Director, Institute for Computational Intelligence<br>
Hampshire College, Amherst, Massachusetts, 01002, USA<br>
<a href="mailto:lspector@hampshire.edu">lspector@hampshire.edu</a>, <a href="http://hampshire.edu/lspector/" rel="noreferrer" target="_blank">http://hampshire.edu/lspector/</a><wbr>, <a href="tel:413-559-5352" value="+14135595352">413-559-5352</a><br>
<br>
______________________________<wbr>_________________<br>
Clusterusers mailing list<br>
<a href="mailto:Clusterusers@lists.hampshire.edu">Clusterusers@lists.hampshire.<wbr>edu</a><br>
<a href="https://lists.hampshire.edu/mailman/listinfo/clusterusers" rel="noreferrer" target="_blank">https://lists.hampshire.edu/<wbr>mailman/listinfo/clusterusers</a><br>
</blockquote></div><br></div>