On 19:21 Wed 26 Mar , Gus Correa wrote:
> On 03/26/2014 05:26 PM, Ross Boylan wrote:
> > [Main part is at the bottom]
> > On Wed, 2014-03-26 at 19:28 +0100, Andreas Schäfer wrote:
> >> On 09:08 Wed 26 Mar , Ross Boylan wrote:
> >>> Second, we do not operate in a batch queuing environment
> >> Why not fix that?
> > I'm not the sysadmin, though I'm involved in the group that sets policy.
> > At one point we were using Sun's grid engine, but I don't think it's
> > installed now. I'm not sure why.
> > We have discussed putting in a batch queuing system and nobody was
> > really pushing for it. My impression was (and probably still is) that
> > it was more pain than gain. There is hassle not only for the sysadmin
> > to set it up (and, I suppose, monitor it), but for users. Personally I
> > run a lot of interactive parallel jobs (the interaction is on rank 0
> > only). I have the impression that won't work under a batch system,
> > though I could be wrong. I also had the impression we'd need to have an
> > estimate of how long the job would run when we submit, and we don't
> > always know.
> But I've never really used such a system, and may not appreciate what it
> would get us. The other reason we haven't bothered is that the load on
> the cluster was relatively light and contention was low. That is less
> and less true, which probably starts tipping the balance toward a
> queuing system.
> This is wandering off topic, but if you or anyone else could say more
> about why you regard the absence of a queuing system as a problem that
> should be fixed, I'd love to hear it.
> Hi Ross
> Some pros:
> (I don't know of any cons.)
I second Gus' statement that there are no real downsides for a
queueing system. These systems actually relieves both, users and
admins from a lot of tedious fiddling and debugging. If you're doing a
fresh install, then I'd suggest you to use Slurm. It's a breeze to
install and easy to maintain. It also integrates well with all major
MPI implementations. Yes, the admin and users need to invest to time
to learn the ropes, but they payoff is almost instant. Source: I'm the
sysadmin for our research clusters.
> Queue systems won't allow resources to be oversubscribed.
I'm fairly confident that you can configure Slurm to oversubscribe
nodes: just specify more cores for a node than are actually present.
> Queue systems do support interactive jobs (even with X-windows GUIs, if
Right, actually we've just moved a couple of systems, which are
primarily running interactive jobs, to Slurm to ease arbitration of
resources. Previously users were frequently stepping on each others
toes (Who's pinning jobs to which core? Who's using which GPU? How
much RAM do you consume?) These problems are gone now.
HPC and Grid Computing
Chair of Computer Science 3
Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
+49 9131 85-27910
PGP/GPG key via keyserver
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!