My current batch queues have a 30-day limit, and I’ll likely be reducing that
to maybe 7 days for most users in the near future, as it will make priority and
fairshare mechanisms more responsive (even if a high-priority job gets bumped
to the top of the queue, it may still have to wait a few day
The simplest is probably to just have a separate partition that will
only allow job times of 1 hour or less.
This is how our Univa queues used to work, by overlapping the same hardware.
Univa shows available "slots" to the users and we had a lot of confused users
complaining about al
There are numerous ways to get this functionality.
The simplest is probably to just have a separate partition that will
only allow job times of 1 hour or less.
There are also options that would involve preemption of the longer jobs
so the quicker ones could run, priorities, etc.
It all depe
Hello
I am looking into switching from Univa (sge) to slurm and am figuring out
how to implement some of our usage policy in slurm.
We have a Univa queue which uses job classes and RQSes to limit jobs with a run
time over 4 hours to only half the available slots (CPU cores) so some slots
ar
