[GE users] Functional policy in heterogeneous environment

Robert Olson olson at mcs.anl.gov
Mon Oct 6 22:22:45 BST 2008

> you might want to defina a "usage_scaling" in the exechost  
> definition, i.e. "qconf -me <hostname>" (man host_conf)

Ah, excellent. I'm guessing I would set a usage_scaling for "cpu" on  
the fast nodes to say 2, which would then have the desired effect on  
the ticket assignment?

> In case of parallel jobs it's seems also necesary to have them  
> completely in one type of machines:
> http://gridengine.info/2006/02/14/grouping-jobs-to-nodes-via-wildcard-pes

I hadn't gotten there yet but probably will this week - thanks.

>> I was planning on setting up a queue for each cluster
> This is not necessary. You can also apply different sequence numbers  
> for hosts or hostgroups in the queuedefintion, like also saving the  
> above mentioned queues to separate parallel apps.

Aha, good. I always forget that you can override many of these  
parameters at the host group level. Though I do like having the  
separate queues for reporting use - qstat -g c giving a nice concise  
view of the utilization of the different flavors. Is there any real  
operational difference between the two approaches? (other than having  
to duplicate common queue configuration if there are multiple queues).

> PS: Additional hint: If you have a directory structure of:
> /opt/bioinformatics/lx24-amd64/bin/myapp
> /opt/bioinformatics/darwin/bin/myapp
> you can have a jobscript to run:
> /opt/bioinformatics/$ARC/bin/myapp
> and you will always get the right binaries while having only one  
> jobscript - whereever you end up

We use a different approach internally to the infrastructure of the  
apps that does essentially the same thing; the bootstrapping of the  
app uses arch or hostname to determine the base location of the  
machine/architecture dependent code (so we can have individual host  
overrides, since $ARCH doesn't distinguish completely for us - in the  
complete environment we have 3-4 different linux flavors that don't  
necessarily all work properly with the same compiled code).


To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list