Am 10.05.2011 um 05:37 schrieb Stuart Barkley:
<snip>
As a simplified user concept the use of the word 'queue' can
convey a useful model and also be a method to apply differing
defaults to a job ("Submit to the short job queue").
No. Specify resource requests in time, memory,... and SGE will
select an appropriate queue for you. Submitting to a queue is
Torque/PBS style.
Actually, this is what I prefer (request what you really want), but
I've been unable to eradicate the concept of distinct queues from our
users. The Internet is full of simplified user instructions to submit
jobs with "-q queuename" (unfortunately they usually don't show the
implementing SGE configurations).
I dislike the fact that someone created "long", "medium" and "short"
as SGE queues for our users and told them all they need to do is
select the correct queue for their job.
They should specify the required time. Even short jobs can end up in a
long queue if it's empty anyway.
I can't change the parameters
of these without users getting unexpected behavior changes.
You could use a JSV to "translate" a queue request to a resource
request.
I do want to have resources with different wall clock limits so that
heavy compute users don't grab all of the available resources for
several weeks. I think this is/should be another FAQ with a few
completely worked example configurations.
Many things can be achieved by just one queue, when you define
different limits for the queue instances in the queue definition for
different machines. All entries can be set for certain machines or
hostgroups.
Do people actually have lots of queues? Or would just 'interactive'
and 'batch' work suitably as queues?
I prefer having as few queues as possible.
-- Reuti
I've picked up a lot of good information in the past couple of weeks.
Now I need to get some time to work with things and try some more
experiments.
Thanks,
Stuart
--
I've never been lost; I was once bewildered for three days, but
never lost!
-- Daniel Boone
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
