Hi All,<div><br></div><div>I was wondering if anyone could confirm my plan or provide a better solution for queue configuration?</div><div><br></div><div>First a bit of jobs and workload context. A small group who work together submit jobs to our grid, these jobs can range from a few GB memory usage to the max we allow per exec host (30 GB now, 384Gb next year). There are two patterns of job submissions: short order and batch jobs (and each could have a big or small memory footprint). When a user so specifies, we would like their job to run immediately or as soon as there are cycles free on the grid. Even though we have a backend high performance distributed filesystem (gluster), our jobs are usually IO bound (we do a lot of one time, random seeks across all of our big data, so caching is pretty much always useless).</div>

<div><br></div><div>Administrative caveats:</div><div>+ cannot kill/restart jobs to manage queue</div><div>+ don't want to swap, ever; because big IO is a big drag</div><div>+ we run ge-6.1</div><div><br></div><div>Our plan for queue reconfiguration, is:</div>

<div>+ two queues: default.q and first.q</div><div>+ h_vmem as a consumable resource</div><div>+ set the first.q priority to something high, like 1000</div><div>+ nice down jobs sent to the default queue</div><div><br></div>

<div>Our 10 hosts have 8 cores each, so we'll configure slots in each queue as:</div><div><br></div><div>slots              1,[host1.dom=8],[host2.dom=8],[host3.dom=8],[host4.dom=8],[host5.dom=8],[host6.dom=8],[host8.dom=8],[host7.dom=8],[host9.dom=8],[host10.dom=8]</div>

<div><br></div><div>and each host will be configured with (only) a h_vmem limit, in complex values.</div><div><br></div><div>With this config we expect exec hosts to receive jobs from both queues (but first.q first) until available memory is used up. We would set a default memory footprint to 1/8 (may experiment with 1/16 or 1/24) available memory In order to prevent too many threads per core. Since the default jobs come with a with nice -n10, the jobs from the first.q would get most of the cpu when both queues might have submit jobs on a single host.</div>

<div><br></div><div>"Run immediately" is not a hard requirement, it is really intended to address getting new jobs (essentially interactive sessions) going asap and before multi hour or multi day jobs finish. To that end maybe it would be better not to configure all slots available to the default queue?</div>

<div><br></div><div>My main question is how to nice down the default queue? Should we make a wrapper for qsub that prepends nice to the command? Another way? I'm also curious if there is a better way to establish appropriate priorities for the queues. And, generally, I welcome your expertise, perhaps there is a better approach?</div>

<div><br></div><div>Looking forward to your reply!</div><div><br></div><div>Regards.</div><div>-George</div><div><br></div><div><br></div><div>-- <br>George Georgalis, <a href="tel:%28415%29%20894-2710" value="+14158942710" target="_blank">(415) 894-2710</a>, <a href="http://www.galis.org/" target="_blank">http://www.galis.org/</a><br>


</div>