<div dir="ltr">Thank you, for the reply  I was beginning to wonder if my message was seen.<div><br></div><div>While I understand how batch systems work, if you have a system daemon that develops a memory leak and consumes the memory outside of allocation.</div><div><br></div><div>Not checking the used memory on the box before dispatch seems like a good way to black hole a bunch of jobs.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 5, 2018 at 7:21 AM, Chris Samuel <span dir="ltr"><<a href="mailto:chris@csamuel.org" target="_blank">chris@csamuel.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday, 26 April 2018 3:28:19 AM AEST Cory Holcomb wrote:<br>
<br>
> It appears that I have a configuration that only takes into account the<br>
> allocated memory before dispatching.<br>
<br>
</span>With batch systems the idea is for the users to set constraints for their jobs <br>
so the scheduler can backfill other jobs onto nodes knowing how much memory <br>
they can rely on.<br>
<br>
So really the emphasis is on making the users set good resource requests (such <br>
as memory) and for the batch system to terminate jobs that exceed them (or to <br>
arrange for the kernel to constrain them to that amount via cgroups).<br>
<br>
Hope that helps!<br>
<span class="HOEnZb"><font color="#888888">Chris<br>
-- <br>
 Chris Samuel  :  <a href="http://www.csamuel.org/" rel="noreferrer" target="_blank">http://www.csamuel.org/</a>  :  Melbourne, VIC<br>
<br>
<br>
</font></span></blockquote></div><br></div>