To provide the most efficient processing of jobs and resources in queues, put the most restrictive rule at the first position of a rule set. Following this convention helps the N1 Grid Engine scheduler to restrict the amount of suited queue instances in a particularly efficient manner, because the first rule is never shadowed by any subsequent rule in the same rule set and thus always stands for itself.
To illustrate this rule, consider an environment similar to the following:
Four queues named Q001-Q004
Four managed resources named F001-F004
Jobs that require a specific managed resource, such as F001, are constrained to run in the associated queue, such as Q001
Jobs are submitted into one of five projects P001-P005
In such an environment, you might define a single rule set as follows:
{ name 30_for_each_project description "not more than 30 per project" enabled TRUE limit projects {*} queues Q001 to F001=30 limit projects {*} queues Q002 to F002=30 limit projects {*} queues Q003 to F003=30 limit projects {*} queues Q004 to F004=30 limit to F001=0,F002=0,F003=0,F004=0 } |
The single rule set limits the utilization of each managed resource to 30 for each project and constrains the jobs in eligible queues at the same time. This will work fine, but in a larger cluster with many hosts, the single rule set would become the cause of slow job dispatching.
To help the N1 Grid Engine scheduler to foreclose as many queue instances as possible during matchmaking, it is better to use four separate rule sets.
{ name 30_for_each_project_in_Q001 description "not more than 30 per project of F001 in Q001" enabled TRUE limit queues !Q001 to F001=0 limit projects {*} queues Q001 to F001=30 } { name 30_for_each_project_in_Q002 description "not more than 30 per project of F002 in Q002" enabled TRUE limit queues !Q002 to F002=0 limit projects {*} queues Q002 to F002=30 } { name 30_for_each_project_in_Q003 description "not more than 30 per project of F003 in Q003" enabled TRUE limit queues !Q003 to F003=0 limit projects {*} queues Q003 to F003=30 } { name 30_for_each_project_in_Q004 description "not more than 30 per project of F004 in Q004" enabled TRUE limit queues !Q004 to F004=0 limit projects {*} queues Q004 to F004=30 } |
These four rule sets constrain the very same per project resource quotas as the single rule set. However, the four rule sets can be processed much more efficiently due to unsuitable queue instances being shielded first . Consolidating these shields into a single resource quota set would not be doable in this case.
The purpose of the sample above is not to recommend one cluster queue per resource. In fact, the! opposite is true, because fewer queues finally always enable fewer, more powerful shields as shown here:
{ name 30_for_each_project_in_Q001 description "not more than 30 per project of F001/F002 in Q001" enabled TRUE limit queues !Q001 to F001=0,F002=0 limit projects {*} queues Q001 to F001=30,F002=30 } { name 30_for_each_project_in_Q002 description "not more than 30 per project of F003/F004 in Q002" enabled TRUE limit queues !Q002 to F003=0,F004=0 limit projects {*} queues Q002 to F003=30,F004=30 } |
In this example, the queues are consolidated from Q001-Q004 down to Q001-Q002. However, this actually increases overall cluster utilization and throughput.