HPC/Submitting and Managing Jobs/Queues and Policies: Difference between revisions

From CNM Wiki
Jump to navigation Jump to search
(broken out from parent)
 
(fleshed out)
Line 1: Line 1:
== Default queue ==
== Introduction ==
The main queue on Carbon is <code>batch</code> and need not be specified.
Job routing decisions on Carbon are handled by the scheduler.
There is one main queue and one debug queue


All job routing decisions are handled by the scheduler. In particular, short jobs are accommodated by a daily reserved node and by ''backfill'' scheduling, i.e. "waving forward" while a big job waits for full resources to become available.
In this framework, short jobs are accommodated by a daily reserved node and by ''backfill'' scheduling,
i.e. "waving forward" small jobs while one or more big jobs wait for full resources to become available.


== Using the debug queue ==
== Default queue "batch" ==
The main queue on Carbon is <code>batch</code> and need not be specified to qsub or in the job script.
The following defaults and limits apply:
 
resources_'''default.nodes = 1:ppn=8'''
resources_'''default.walltime = 00:15:00'''    # 15 min
resources_'''max.walltime = 240:00:00'''      # 10 days
max_user_queuable = 2000
And, given current node hardware:
ppn &le; 8
 
In addition, the Moab scheduler applies various per-user limits. One is the number of jobs ''eligible to run'' (MAXIPROC). This concept is similar to that a line of people waiting outside a building vs. those permitted to wait inside the lobby.
 
See also:
* [http://www.adaptivecomputing.com/resources/docs/torque/4.1queueconfig.php Torque queue configuration].
* [http://www.adaptivecomputing.com/resources/docs/mwm/6.2throttlingpolicies.php Moab Usage Limits/Throttling Policies].
 
== Queue "debug" ==
For testing job processing and your job environment, use <code>qsub '''-q debug'''</code> on the command line, or the follwing in a job script:
For testing job processing and your job environment, use <code>qsub '''-q debug'''</code> on the command line, or the follwing in a job script:
  #PBS '''-q debug'''
  #PBS '''-q debug'''
The debug queue accepts jobs under the following conditions
The debug queue accepts jobs under the following conditions
  nodes &le; 2
resources_'''default.nodes = 1:ppn=4'''
resources_'''max.nodes = 4:ppn=4'''
resources_'''default.walltime = 00:15:00'''
resources_'''max.walltime = 01:00:00'''
max_user_queuable = 3
max_user_run = 2
in other words,
  nodes &le; 4
  ppn &le; 4
  ppn &le; 4
  walltime &le; 1:00:00
  walltime &le; 1:00:00   # 1 hour

Revision as of 04:34, May 24, 2011

Introduction

Job routing decisions on Carbon are handled by the scheduler. There is one main queue and one debug queue

In this framework, short jobs are accommodated by a daily reserved node and by backfill scheduling, i.e. "waving forward" small jobs while one or more big jobs wait for full resources to become available.

Default queue "batch"

The main queue on Carbon is batch and need not be specified to qsub or in the job script. The following defaults and limits apply:

resources_default.nodes = 1:ppn=8
resources_default.walltime = 00:15:00    # 15 min
resources_max.walltime = 240:00:00       # 10 days
max_user_queuable = 2000

And, given current node hardware:

ppn ≤ 8

In addition, the Moab scheduler applies various per-user limits. One is the number of jobs eligible to run (MAXIPROC). This concept is similar to that a line of people waiting outside a building vs. those permitted to wait inside the lobby.

See also:

Queue "debug"

For testing job processing and your job environment, use qsub -q debug on the command line, or the follwing in a job script:

#PBS -q debug

The debug queue accepts jobs under the following conditions

resources_default.nodes = 1:ppn=4
resources_max.nodes = 4:ppn=4
resources_default.walltime = 00:15:00
resources_max.walltime = 01:00:00
max_user_queuable = 3
max_user_run = 2

in other words,

nodes ≤ 4
ppn ≤ 4
walltime ≤ 1:00:00    # 1 hour