specifies account specific attributes. See the account overview for general information and the job flag overview for a description of legal flag values.
EXAMPLE
PARAMETER
ACCOUNTINGINTERFACEURL
FORMAT
<URL> where protocol can be one of exec, file, or sql
DEFAULT
---
DETAILS
specifies the interface to use for real-time export of Moab accounting/auditing information. See Exporting Events in Real-Time for more information.
EXAMPLE
PARAMETER
ACCOUNTWEIGHT
FORMAT
<INTEGER>
DEFAULT
1
DETAILS
specifies the priority weight to be applied to the specified account priority. (See Credential (CRED) Factor)
EXAMPLE
PARAMETER
ADMINCFG[X]
FORMAT
one or more <ATTR>=<VALUE> pairs
where <ATTR> is one of the following: ENABLEPROXY, USERS, SERVICES, or NAME
DEFAULT
---
DETAILS
allows a site to configure which services and users belong to a particular level of administration. NOTE: The first user listed in the ADMINCFG[1] users list is considered to be the 'primary admin'
EXAMPLE
Members of the batchadmin admin role are allowed to run all commands. Members of the helpdesk role are allowed to cancel jobs, adjust job priority, and adjust job holds. They are also able to view and modify credential objects (ie, users, groups, accounts, etc) See the security overview for more details.
PARAMETER
ADMIN1, ADMIN2, ADMIN3
FORMAT
space delimited list of user names
DEFAULT
root
DETAILS
users listed under the parameter ADMIN1 are allowed to perform any scheduling function. They have full control over the scheduler and access to all data. The first user listed in the ADMIN1 user list is considered to be the 'primary admin' and is the ID under which Moab must be started and run. Valid values include user names or the keyword 'ALL'. These parameters are deprecated, use ADMINCFG.
EXAMPLE
all users listed have full access to Moab control commands and Moab data. Moab must be started by and run under the 'moabuser' user id since moabuser is the primary admin.
PARAMETER
ALLOWROOTJOBS
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether batch jobs from the root user (UID=0) are allowed to be execute (NOTE: the resource manager must also support root jobs).
specifies the interface and policy configuration for the scheduler-allocation manager interface. Described in detail in the Allocation Manager Configuration Overview
EXAMPLE
the QBank server will be contacted at port 7111 on host supercluster.org
PARAMETER
APPLICATIONLIST
FORMAT
space delimited list of generic resources
DEFAULT
N/A
DETAILS
specifies which generic resources
represent actual applications on the cluster/grid.
(See 12.4 - Consumable Generic Resources for more information.)
EXAMPLE
the generic resources 'calclab' and 'powerhouse' will now be recognized and treated as application software
PARAMETER
ATTRATTRWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the priority weight to be applied to jobs with the specified job attribute. (See Attribute (ATTR) Factor)
specifies the priority weight to be applied to jobs with the specified job state. (See Attribute (ATTR) Factor)
EXAMPLE
PARAMETER
ATTRWEIGHT
FORMAT
<INTEGER>
DEFAULT
1
DETAILS
specifies the priority component weight to be applied to the ATTR subcomponents. (See Attribute (ATTR) Factor)
EXAMPLE
PARAMETER
BACKFILLDEPTH
FORMAT
<INTEGER>
DEFAULT
0 (no limit)
DETAILS
specifies the number idle jobs to evaluate for backfill. The backfill algorithm will evaluate the top <X> priority jobs for scheduling. By default, all jobs are evaluated.
EXAMPLE
evaluate only the top 128 highest priority idle jobs for consideration for backfill
PARAMETER
BACKFILLMETRIC
FORMAT
one of the following PROCS, PROCSECONDS, SECONDS,
or NODES
DEFAULT
PROCS
DETAILS
specifies the criteria used by the backfill algorithm to determine the
'best' jobs to backfill. Only applicable when using BESTFIT or GREEDY
backfill algorithms
EXAMPLE
PARAMETER
BACKFILLPOLICY
FORMAT
one of the following: FIRSTFIT,
BESTFIT, GREEDY, OPTIMISTIC, PREEMPT, or NONE
DEFAULT
FIRSTFIT
DETAILS
specifies what backfill algorithm will be used. See Configuring Backfill for more information.
EXAMPLE
PARAMETER
BFCHUNKDURATION
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0 (chunking disabled)
DETAILS
specifies the duration during which freed resources will be aggregated for use by larger jobs. Used in conjunction with BFCHUNKSIZE. See Configuring Backfill for more information.
EXAMPLE
aggregate backfillable resources for up to 5 minutes, making resources available only to jobs of size 4 or larger
PARAMETER
BFCHUNKSIZE
FORMAT
<INTEGER>
DEFAULT
0 (chunking disabled)
DETAILS
specifies the minimum job size which can utilize chunked resources. Used in conjunction with BFCHUNKDURATION. See Configuring Backfill for more information
EXAMPLE
aggregate backfillable resources for up to 5 minutes, making resources available only to jobs of size 4 or larger
PARAMETER
BFPRIORITYPOLICY
FORMAT
one of RANDOM, DURATION, or HWDURATION
DEFAULT
---
DETAILS
specifies policy to use when prioritizing backfill jobs for preemption
EXAMPLE
use length of job in determining which backfill job to preempt
PARAMETER
BFMINVIRTUALWALLTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
---
DETAILS
specifies the minimum job wallclock time for virtual scaling (optimistic-like backfilling.) Any job with a wallclock time less than this setting will not be virtually scaled.
EXAMPLE
PARAMETER
BFVIRTUALWALLTIMECONFLICTPOLICY
FORMAT
one of the following: PREEMPT
DEFAULT
---
DETAILS
specifies how to handle scheduling conflicts when a virtually scaled job "expands" to its original wallclock time (this occurs when the job is within one scheduling iteration - RMPOLLINTERVAL - of its virtually scaled wallclock time expiring.)
EXAMPLE
PARAMETER
BFVIRTUALWALLTIMESCALINGFACTOR
FORMAT
<DOUBLE>
DEFAULT
0 (virtual scaling disabled)
DETAILS
specifies the factor by which eligible jobs' wallclock time is virtually scaled (optimistic-like backfilling.)
EXAMPLE
PARAMETER
BLOCKLIST
FORMAT
DEPEND
DEFAULT
NONE
DETAILS
specifies the additional non-default criteria which are used to determine if a job should be filtered out before idle usage is updated and idle usage policies are enforced
EXAMPLE
PARAMETER
BYPASSCAP
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the max weighted value allowed from the bypass count subfactor when determining a job's priority (see Priority Factors for more information)
EXAMPLE
PARAMETER
BYPASSWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the weight to be applied to a job's backfill bypass count when determining a job's priority (see Priority Factors for more information)
EXAMPLE
PARAMETER
CHECKPOINTEXPIRATIONTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
INFINITY
DETAILS
specifies how 'stale' checkpoint data can be before it is ignored and
purged.
EXAMPLE
Expire checkpoint data which has been stale for over one day
PARAMETER
CHECKPOINTFILE
FORMAT
<STRING>
DEFAULT
moab.ck
DETAILS
name (absolute or relative) of the Moab checkpoint file.
EXAMPLE
Maintain the Moab checkpoint file in the file specified
PARAMETER
CHECKPOINTINTERVAL
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
00:05:00
DETAILS
time between automatic Moab checkpoints
EXAMPLE
Moab should checkpoint state information every 15 minutes
one or more of <ATTR>-<VALUE> pairs where <X> indicates the specified peer and <ATTR> is one of the following: AUTH, AUTHCMD, AUTHTYPE, HOST, KEY, or DEFAULTSUBMITPARTITION
DEFAULT
---
DETAILS
specifies the shared secret key and authentication method which Moab will use to communicate with the named peer daemon. See Security Overview for more information. NOTE: The AUTHTYPE and KEY attributes of this parameter may only be specified in the moab-private.cfg config file
EXAMPLE
Moab will use the session key apple7 for peer authentication and for
encrypting and decrypting messages sent from silverB. Also, client
connections from this interface will be authorized at an admin 1 level
PARAMETER
CLIENTMAXPRIMARYRETRY
FORMAT
<integer> or INFINITY
DEFAULT
1
DETAILS
specifies how many times the client will attempt to retry its connection to the primary server if moab is not available.
EXAMPLE
The client will attempt to retry its connection to the primary server 5 times with 1 second intervals before giving up.
NOTE: If INFINITY is specified, moab will attempt 2140000000 times.
PARAMETER
CLIENTMAXPRIMARYRETRYTIMEOUT
FORMAT
<integer> (milliseconds)
DEFAULT
2 seconds
DETAILS
specifies how much time to wait until the client will attempt to retry its connection to the primary server if moab is not available.
EXAMPLE
The client will attempt to retry its connection to the primary server 3 times with 1/2 second intervals before giving up.
PARAMETER
CLIENTTIMEOUT
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
00:00:30
DETAILS
time which Moab client commands will wait for a response from the Moab server See Client Configuration for more information. (NOTE: may also be specified as an environment variable)
EXAMPLE
Moab clients will wait up to 15 minutes for a response from the
server before timing out
PARAMETER
CREDDISCOVERY
FORMAT
TRUE
DEFAULT
FALSE
DETAILS
Specifies that Moab should create otherwise unknown credentials when it discovers them in the statistics files.
specifies what to do when a requested deadline cannot be reached (See Job Deadlines)
EXAMPLE
PARAMETER
DEFAULTCLASSLIST
FORMAT
space delimited list of one or more <STRING>'s
DEFAULT
---
DETAILS
specifies the default classes supported on each node for RM systems which do not provide this information
EXAMPLE
PARAMETER
DEFAULTSUBMITLANGUAGE
FORMAT
one of LSF, PBS, LL or SLURM
DEFAULT
PBS
DETAILS
specifies the default job language to use when interpreting commandline arguments and command file scripts associated with the msub command.
EXAMPLE
PARAMETER
DEFAULTSUBMITPARTITION
FORMAT
see parameter CLIENTCFG[]
DEFAULT
---
DETAILS
If a user submits a job using msub which does not specify host, feature, or partition constraints, then the msub client will insert the specified default submit partition into the newly submitted job as a hard requirement.
EXAMPLE
PARAMETER
DEFERCOUNT
FORMAT
<INTEGER>
DEFAULT
24
DETAILS
specifies the number of times a job can be deferred before it will be placed in batch hold.
EXAMPLE
PARAMETER
DEFERSTARTCOUNT
FORMAT
<INTEGER>
DEFAULT
1
DETAILS
specifies the number of times a job will be allowed to fail in its start attempts before being deferred. NOTE: A job's startcount will increase each time a start request is made to the resource manager regardless of whether or not this request succeeded. This means start count increases if job starts fail or if jobs are started and then rejected by the resource manager.
EXAMPLE
PARAMETER
DEFERTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
1:00:00
DETAILS
specifies the amount of time a job will be held in the deferred state before being released back to the Idle job queue NOTE: A job's defer time will be restarted if Moab is restarted.
EXAMPLE
PARAMETER
DIRECTORYSERVER
FORMAT
<HOST>[:<PORT>]
DEFAULT
---
DETAILS
specifies the interface for the directory server
EXAMPLE
PARAMETER
DISABLESAMEQOSPREEMPTION
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether or not a preemptor job can preempt a preemptee job which possesses the same QoS.
EXAMPLE
PARAMETER
DISABLESCHEDULING
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether or not the scheduler will schedule jobs. If set to TRUE, Moab will continue to update node and job state but will not start, preempt, or otherwise modify jobs. The command mschedctl -r will clear this parameter and resume normal scheduling.
EXAMPLE
PARAMETER
DISABLESLAVEJOBSUBMIT
FORMAT
<BOOLEAN>
DEFAULT
TRUE
DETAILS
This parameter can be added to the moab.cfg file on a slave Moab server (in a grid configuration) to prevent users from submitting jobs to the master Moab server from the slave Moab server. Some grid configurations allow the user to submit jobs on the slave that are migrated to the master and submitted from the master. Other grid configurations do not allow the jobs to be migrated to the master from the slave, in which case, jobs submitted from the slave remain idle on the slave and never run. This parameter will reject the job submissions on the slave to prevent the submission of jobs that will never run.
EXAMPLE
PARAMETER
DISKWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the priority weight to be applied to the amount of dedicated disk space required per task by a job (in MB)
EXAMPLE
if a job requires 12 tasks and 512 MB per task of dedicated local disk space, Moab will increase the job's priority by 10 * 100 * 12 * 512
PARAMETER
DISPLAYFLAGS
FORMAT
one or more of the following values (space delimited)
ACCOUNTCENTRIC, HIDEBLOCKED, or NODECENTRIC
DEFAULT
---
DETAILS
specifies flags which control how Moab client commands will display various information. ACCOUNTCENTRIC will display account information in showq, rather than group information HIDEBLOCKED will prevent showq from listing information about blocked jobs which are not owned by the user if the user is not an admin NODECENTRIC will display node allocation information instead of processor allocation information in showq
EXAMPLE
PARAMETER
ENABLEFSVIOLATIONPREEMPTION
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
if set to TRUE, Moab will allow jobs within the same class/queue to preempt when the preemptee is violating a fairshare target and the preemptor is not.
EXAMPLE
PARAMETER
EMULATIONMODE
FORMAT
{ SLURM }
DEFAULT
---
DETAILS
specifies whether or not the scheduler will preform the automatic setup of a particular resource manager environment
EXAMPLE
Moab will perform the automated setup steps as if it were interfacing with a slurm resource manager (automatic QOS creation).
PARAMETER
ENABLEMULTINODEJOBS
FORMAT
<BOOLEAN>
DEFAULT
TRUE
DETAILS
specifies whether or not the scheduler will allow jobs to span more than one node
EXAMPLE
PARAMETER
ENABLEMULTIREQJOBS
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether or not the scheduler will allow jobs to specify multiple independent resource requests (i.e., PBS jobs with resource specifications such as '-l nodes=3:fast+1:io')
EXAMPLE
PARAMETER
ENABLENEGJOBPRIORITY
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
if set to TRUE, the scheduler will allow job priority value to range from -INFINITY to MMAX_PRIO, otherwise, job priority values are given a lower bound of '1'. (see REJECTNEGPRIOJOBS)
EXAMPLE
Job priority may range from -INFINITY to MMAX_PRIO.
PARAMETER
ENABLENODEADDRLOOKUP
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
if set to TRUE, the scheduler will use the default
host name service lookup mechanism (i.e., /etc/hosts, DNS, NIS, etc) to determine the IP address of the nodes reported by the resource manager. This information is used to correlate information reported by multi-homed hosts.
EXAMPLE
PARAMETER
ENABLEPOSUSERPRIORITY
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
if set to TRUE, the
scheduler will allow users to specify positive job priority values which will be honored.
In other words, users can specify a priority that falls in the range of -1024
to +1023, inclusive. If set to FALSE (the default), user priority values are given an upper bound of '0' when users request a positive priority.
EXAMPLE
Users may now specify positive job priorities and have them take effect (e.g. msub -p 100 job.cmd).
PARAMETER
ENABLESPVIOLATIONPREEMPTION
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
if set to TRUE, Moab will allow jobs within the same class/queue to preempt when the preemptee is violating a softusage policy and the preemptor is not.
EXAMPLE
PARAMETER
ENABLESTARTESTIMATESTATS
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
if set to TRUE, Moab will collect job start time estimation stats for all submitted jobs and will use those statistics to improve future estimates. Resource availability queries which can utilize this info can be made using the showstart command. Current estimation statistics can be viewed using the mdiag -S command. To flush current statistics, use the mschedctl -f command. NOTE: This parameter can be resource intensive so sites with large job queues (>10,000 jobs) may want to consider leaving this set to FALSE, see Considerations for Large Clusters for more details.
EXAMPLE
PARAMETER
ENFORCEACCOUNTACCESS
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether or not Moab will enforce account access constraints without an allocation manager.
EXAMPLE
PARAMETER
ENFORCEINTERNALCHARGING
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether or not the scheduler will enforce internal credit tracking (see Internal Charging).
EXAMPLE
PARAMETER
EVENTSERVER
FORMAT
<HOST>[:<PORT>]
DEFAULT
---
DETAILS
specifies the interface for the event server
EXAMPLE
PARAMETER
FEATURENODETYPEHEADER
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies the header used to specify node type via node features (ie,
LL features or PBS node attributes).
EXAMPLE
Moab will interpret all node features with the leading string xnt as a nodetype specification - as used by QBank and other allocation managers, and assign the associated value to the node. i.e., xntFast
PARAMETER
FEATUREPARTITIONHEADER
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies the header used to specify node partition via node features
(ie, LL features or PBS node attributes).
EXAMPLE
Moab will interpret all node features with the leading string xpt as a partition specification and assign the associated value to the node. i.e., xptGold
PARAMETER
FEATUREPROCSPEEDHEADER
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies the header used to extract node processor speed via node features (i.e., LL features or PBS node attributes). NOTE: Adding a trailing '$' character will specifies that only features with a trailing number be interpreted. For example, the header 'sp$' will match 'sp450' but not 'sport'
EXAMPLE
Moab will interpret all node features with the leading string xps as a processor speed specification and assign the associated value to the node. i.e., xps950
PARAMETER
FEATURERACKHEADER
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies the header used to extract node rack index via node features (i.e., LL features or PBS node attributes). NOTE: Adding a trailing '$' character will specifies that only features with a trailing number be interpreted. For example, the header 'rack$' will match 'rack4' but not 'racket'
EXAMPLE
Moab will interpret all node features with the leading string rack as a rack index specification and assign the associated value to the node. i.e., rack16
PARAMETER
FEATURESLOTHEADER
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies the header used to extract node slot index via node features (i.e., LL features or PBS node attributes). NOTE: Adding a trailing '$' character will specifies that only features with a trailing number be interpreted. For example, the header 'slot$' will match 'slot12' but not 'slotted'
EXAMPLE
Moab will interpret all node features with the leading string slot as a slot index specification and assign the associated value to the node. i.e., slot16
PARAMETER
FEEDBACKPROGRAM
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies the name of the program to be run at the completion of each job. If not fully qualified, Moab will attempt to locate this program
in the 'tools' subdirectory.
EXAMPLE
Moab will run the specified program at the completion of each job.
PARAMETER
FILEREQUESTISJOBCENTRIC
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether a job's file request is a total request for the job or a per task request
EXAMPLE
Moab will treat file requests as a total request per job
PARAMETER
FORCERSVSUBTYPE
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies that admin reservations must have a subtype associated with them
EXAMPLE
Moab will require all admin reservations to include a subtype
PARAMETER
FSACCOUNTWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the weight assigned to the account subcomponent of the fairshare
component of priority
EXAMPLE
PARAMETER
FSCAP
FORMAT
<DOUBLE>
DEFAULT
0 (NO CAP)
DETAILS
specifies the maximum allowed absolute value for a job's total pre-weighted fairshare
component
EXAMPLE
Moab will bound a job's pre-weighted fairshare component by the range +/- 10.0
PARAMETER
FSCLASSWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the weight assigned to the class subcomponent of the fairshare component of priority
EXAMPLE
PARAMETER
FSDECAY
FORMAT
<DOUBLE>
DEFAULT
1.0
DETAILS
specifies decay rate applied to past fairshare interval when computing effective fairshare usage. Values may be in the range of 0.01 to 1.0. A smaller value causes more rapid decay causing aged usage to contribute less to the overall effective fairshare usage. A value of 1.0 indicates that no decay will occur and all fairshare intervals will be weighted equally when determining effective fairshare usage. (See Fairshare Overview)
EXAMPLE
Moab will apply a decay rate of 0.8 to all fairshare windows
PARAMETER
FSDEPTH
FORMAT
<INTEGER>
DEFAULT
8
DETAILS
NOTE: The number of available fairshare windows is bounded by the MAX_FSDEPTH value (32 in Moab). See Fairshare Overview
specifies the fairshare weight assigned to jobs per user
EXAMPLE
PARAMETER
FSPOLICY
FORMAT
<POLICY>[*] where <POLICY> is one of the following: DEDICATEDPS, DEDICATEDPES, UTILIZEDPS, PDEDICATEDPS, or SDEDICATEDPES
DEFAULT
---
DETAILS
specifies the unit of tracking fairshare usage. DEDICATEDPS tracks dedicated processor seconds. DEDICATEDPES tracks dedicated processor-equivalent seconds. UTILIZEDPS tracks the number of utilized processor seconds. SDEDICATEDPES tracks dedicated processor-equivalent seconds scaled by the speed of the node. PDEDICATEDPS tracks dedicated processor seconds scaled by the processor speed of the node. If the optional '%' (percentage) character is specified, percentage based fairshare will be used. See Fairshare Overview and Fairshare Consumption Metrics or more information.
EXAMPLE
Moab will track fairshare usage by dedicated process-equivalent seconds
PARAMETER
FSPPUWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the fairshare weight assigned to processors per user.
EXAMPLE
PARAMETER
FSPSPUWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the fairshare weight assigned to processor-seconds per user.
EXAMPLE
PARAMETER
FSQOSWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the priority weight assigned to the QOS fairshare subcomponent
EXAMPLE
PARAMETER
FSTARGETISABSOLUTE
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether Moab should base fairshare targets off of delivered cycles or up/available cycles.
EXAMPLE
PARAMETER
FSTREE
FORMAT
list of zero or more space delimited <ATTR>=<VALUE> pairs where <ATTR> is one of the following: SHARES or MEMBERLIST
Credentials will be given access to their parent node when applicable
PARAMETER
FSTREEISREQUIRED
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether a job must have an applicable node in the partition's FSTREE in order to execute within that partition (see Hierarchical Share Tree Overview)
EXAMPLE
Jobs must have an applicable node in the FSTREE in order to execute
Users must be given explicit access to FSTREE nodes in order to gain access to the FSTREE
PARAMETER
FSUSERWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the priority weight assigned to the user fairshare subfactor.
EXAMPLE
PARAMETER
FSWEIGHT
FORMAT
<INTEGER>
DEFAULT
1
DETAILS
specifies the priority weight assigned to the summation of the fairshare subfactors (see Priority Factor and Fairshare overviews)
EXAMPLE
PARAMETER
GEVENTCFG[<GEVENT>]
FORMAT
list of zero or more space delimited <ATTR
>=<VALUE> pairs where <ATTR> is one of the following: ACTION or REARM
DEFAULT
---
DETAILS
specifies how scheduler should behave when
various cluster events are detected. See the Generic Events Overview.
EXAMPLE
If a hitemp event is detected, Moab will adjust the node allocation policy to
minimize the allocation of the node. Moab will also send emails to cluster admins
and report the event in the Moab event log.
PARAMETER
GRESCFG[<GRES>]
FORMAT
list of zero or more space delimited <ATTR
>=<VALUE> pairs where <ATTR> is one of the following: TYPE
Jobs which request the generic resources matlab or ccs will have a corresponding job attribute assigned to them.
PARAMETER
ENABLEHIGHTHROUGHPUT
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
configures Moab so that it will accept msub submissions, start jobs, process triggers, etc., in a manner which
minimizes their processing time. The downside is that Moab will return minimal information about these jobs at submit time (no job ID is returned). It is recommended
that jobs be submitted with a "-N <JOBNAME>" argument so users can keep track of their jobs.
EXAMPLE
Moab can now accept hundreds of jobs per second using msub instead of 20-30.
PARAMETER
GROUPCFG[<GROUPID>]
FORMAT
list of zero or more space delimited <ATTR>=<VALUE> pairs where <ATTR> is one of the following: General Credential Flags,
PRIORITY, ENABLEPROFILING, FSTARGET, QLIST,
QDEF, PLIST, PDEF, FLAGS, or a fairness policy specification.
DEFAULT
---
DETAILS
specifies group specific attributes. See the
flag overview
for a description of legal flag values.
EXAMPLE
up to 50 jobs submitted by members of the group staff will be allowed to execute simultaneously and will be assigned the QOS highprio by default.
PARAMETER
GROUPWEIGHT
FORMAT
<INTEGER>
DEFAULT
1
DETAILS
specifies the priority weight assigned to the specified group priority
(See Credential (CRED) Factor)
EXAMPLE
PARAMETER
HAPOLLINTERVAL
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
30
DETAILS
specifies the amount of time between subsequent high availability pings. (See High Availability Overview for more info)
EXAMPLE
The Moab fallback server will check the health of the Moab primary every 15 seconds.
PARAMETER
IDCFG[X]
FORMAT
one or more of the following attribute/value pairs: BLOCKEDCREDLIST, CREATECRED, CREATECREDURL, REFRESHPERIOD, RESETCREDLIST or SERVER
DEFAULT
---
DETAILS
This parameter enables the identity manager interface allowing credential, policy, and usage information to be shared with an external information service.
EXAMPLE
Moab will refresh credential info every hour using the specified script.
PARAMETER
IGNORECLASSES
FORMAT
[!]<CLASS>[,<CLASS>]...
DEFAULT
---
DETAILS
By default, jobs from all listed classes are ignored and
not scheduled, tracked, or otherwise processed by Moab. If the not (i.e., '!') character is
specified, only jobs from listed classes are processed. (see Moab Side by Side Analysis)
EXAMPLE
Moab will ignore jobs from classes dque and batch.
PARAMETER
IGNOREJOBS
FORMAT
[!]<JOBID>[,<JOBID>]...
DEFAULT
---
DETAILS
By default, listed jobs are ignored and not scheduled, tracked, or otherwise processed by Moab. If the not (i.e., '!') character is specified, only listed jobs are processed. (see Moab Side by Side Analysis)
EXAMPLE
Moab will ignore jobs all classes except 14221 and 14223.
PARAMETER
IGNORENODES
FORMAT
[!]<NODE>[,<NODE>]...
DEFAULT
---
DETAILS
By default, all listed nodes are ignored and
not scheduled, tracked, or otherwise processed by Moab. If the not (i.e., '!') character is
specified, only listed nodes are processed. (see Moab Side by Side Analysis)
EXAMPLE
Moab will only process nodes host3 and host4.
PARAMETER
IGNOREPREEMPTEEPRIORITY
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
By default, preemptor jobs can only preempt preemptee jobs if the preemptor has a higher job priority than the preemptee. When this parameter is set to true, the priority constraint is removed allowing any preemptor to preempt any preemptee.
EXAMPLE
All preemptor job can preempt any preemptee jobs.
PARAMETER
IGNOREUSERS
FORMAT
[!]<USERNAME>[,<USERNAME>]...
DEFAULT
---
DETAILS
By default, jobs from all listed users are ignored and
not scheduled, tracked, or otherwise processed by Moab. If the not (i.e.,
'!') character is specified, only jobs from listed users are processed. (see Moab Side by Side Analysis)
EXAMPLE
Moab will ignore jobs from users testuser1 and annapolis.
PARAMETER
#INCLUDE
FORMAT
<STRING>
DEFAULT
---
DETAILS
specifies another file which contains more
configuration parameters.
EXAMPLE
Moab will process the parameters in moab.acct as well as moab.cfg
PARAMETER
INSTANTSTAGE
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether Moab should instantly stage jobs to the underlying resource manager when a job is submitted through msub.
EXAMPLE
PARAMETER
INVALIDFSTREEMSG
FORMAT
"<STRING>"
DEFAULT
"no valid fstree node found"
DETAILS
specifies the error message that should be attached to jobs that cannot run because of a fairshare tree configuration violation.
EXAMPLE
PARAMETER
JOBACTIONONNODEFAILURE
FORMAT
one of CANCEL, FAIL, HOLD, IGNORE, MIGRATE, NOTIFY, or REQUEUE
DEFAULT
---
DETAILS
specifies the action to take if Moab detects that a node allocated to an active job has failed (state is down). By default, Moab only reports this information via diagnostic commands. If this parameter is set, Moab will cancel or requeue the active job.
EXAMPLE
Moab will requeue active jobs which have allocated nodes which have failed during the execution of the job.
PARAMETER
JOBAGGREGATIONTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0
DETAILS
specifies the minimum amount of time the scheduler should wait after receiving a job event until it should process that event. This parameter allows sites with bursty job submissions to process job events in groups decreasing total job scheduling cycles and allowing the scheduler to make more intelligent choices by aggregating job submissions and choosing between the jobs. (See Considerations for Large Clusters)
EXAMPLE
Moab will wait 4 seconds between scheduling cycles when job events have been received and will wait 30 seconds between scheduling cycles otherwise
specifies attributes for jobs which satisfy the specified profile. NOTE: The index to the JOBCFG parameter can either be an admin-chosen job template name or the exact name of job reported by one or more workloadqueries. See Wiki Attributes, Dynamic Jobs and Job Template Extensions
EXAMPLE
When the sql job is detected, it will have the specified default qos and node feature attributes set.
PARAMETER
JOBCPURGETIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
00:05:00
DETAILS
Specifies the amount of time Moab will preserve detailed information about a completed job (see JOBPURGETIME, showq -c and checkjob)
EXAMPLE
Moab will maintain detailed job information for two hours after a job has completed.
specifies the job templates which must be matched and which will be applied in the case of a match.
EXAMPLE
PARAMETER
JOBMAXHOLDTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
---
DETAILS
Specifies the amount of time a job can be held before it is canceled automatically.
EXAMPLE
Moab will keep jobs in any HOLD state for 2 hours before canceling them.
PARAMETER
JOBMAXNODECOUNT
FORMAT
<INTEGER>
DEFAULT
1024
DETAILS
specifies the maximum number of nodes which
can be allocated to a job. After changing this parameter, Moab must be restarted.
NOTE: This value cannot exceed either MMAX_NODE or
MMAX_TASK_PER_JOB. If larger values are required, these values must also be
increased. Moab must be restarted before changes to this command will take affect.
The command mdiag -S will
indicate if any job node count overflows have occurred. (see Consideration for Large Clusters)
EXAMPLE
PARAMETER
JOBMAXOVERRUN
FORMAT
[[[[DD:]HH:]MM:]SS,][[[DD:]HH:]MM:]SS
DEFAULT
(no soft limit), 10 minutes (hard limit)
DETAILS
soft and hard limit of the amount of time Moab will allow a job to exceed its wallclock limit before it first sends a mail to the primary admin (soft limit) and then terminates the job (hard limit). See WCVIOLATIONACTION or Resource Usage Limit Overview.
EXAMPLE
Jobs may exceed their wallclock limit by up to 1 hour, but Moab will send an email to the primary administrator when a job exceeds its walltime by 15 minutes
PARAMETER
JOBMAXPREEMPTPERITERATION
FORMAT
<INTEGER>
DEFAULT
0 (No Limit)
DETAILS
maximum number of jobs allowed to be preempted per iteration
EXAMPLE
PARAMETER
JOBMAXSTARTPERITERATION
FORMAT
<INTEGER>
DEFAULT
0 (No Limit)
DETAILS
maximum number of jobs allowed to start per iteration
EXAMPLE
PARAMETER
JOBMAXSTARTTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
-1 (NO LIMIT)
DETAILS
length of time a job is allowed to remain in a 'starting' state. If a 'started' job does not transition to a running state within this amount of time, Moab will cancel the job, believing a system failure has occurred.
EXAMPLE
jobs may attempt to start for up to 2 hours before being canceled by the scheduler
PARAMETER
JOBNODEMATCHPOLICY
FORMAT
zero or more of the following: EXACTNODE or EXACTPROC
DEFAULT
---
DETAILS
specifies additional constraints on how compute nodes are to be selected.
EXACTNODE indicates that Moab should select as many nodes as requested even if it could pack multiple tasks onto the same node. EXACTPROC indicates that Moab should select only nodes with exactly the number of processors configured as are requested per node even if nodes with excess processors are available.
EXAMPLE
In a PBS/Native job with resource specification 'nodes=<x>:ppn=<y>', Moab will allocate exactly <y> task on each of <x> distinct nodes.
PARAMETER
JOBPREEMPTMINACTIVETIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0
DETAILS
The minimum amount of time a job must be active before being considered eligible for preemption. (See Job Preemption)
EXAMPLE
A job must execute for 5 minutes before Moab will consider it eligible for preemption.
PARAMETER
JOBPRIOACCRUALPOLICY
FORMAT
one of the following: ALWAYS, FULLPOLICY, QUEUEPOLICY
DEFAULT
QUEUEPOLICY
DETAILS
specifies how the dynamic aspects of a job's priority will be adjusted. ALWAYS indicates that the job will accrue queuetime based priority from the time it is submitted. FULLPOLICY indicates that it will accrue priority only when it is idle and meets all idle AND run queue policies. QUEUEPOLICY indicates that it will accrue priority so long as it is idle and satisfies idle queue policies, i.e. MAXJOBQUEUED. NOTE: Unless the policy ALWAYS is set, jobs will not accrue policy while a user, system, or batch hold is in place. (see Job Priority Overview)
EXAMPLE
Moab will adjust the job's dynamic priority subcomponents, i.e., QUEUETIME, XFACTOR, and TARGETQUEUETIME, etc. each iteration that the job satisfies the associated 'QUEUE' policies such as MAXJOBQUEUED.
PARAMETER
JOBPRIOF
FORMAT
<ATTRIBUTE>[<VALUE>]=<PRIORITY> where <ATTRIBUTE> is one of ATTR, GRES or STATE
DEFAULT
---
DETAILS
specifies attribute priority weights for jobs with specific attributes, generic resource requests, or states. State values must be one of the standard Moab job states. (see Attribute Based Job Prioritization)
EXAMPLE
Moab will adjust the job's dynamic priority subcomponents.
PARAMETER
JOBPURGETIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0 (purge immediately if the resource manager does not report the job)
DETAILS
The amount of time Moab will keep a job record which is no longer reported by the resource manager. Useful when using a resource manager which drops information about a job due to internal failures. (see JOBCPURGETIME)
EXAMPLE
Moab will maintain a job record for 5 minutes after the last update regarding that object received from the resource manager.
PARAMETER
JOBREJECTPOLICY
FORMAT
zero or more of CANCEL, HOLD, IGNORE (beta), MAIL, or RETRY
DEFAULT
CANCEL
DETAILS
specifies the action to take when
the scheduler determines that a job can never run. CANCEL issues a
call to the resource manager to cancel the job. HOLD places a
batch hold on the job preventing the job from being further evaluated
until released by an administrator. (NOTE: Administrators can
dynamically alter job attributes and possibly fix the job with mjobctl -m.) With IGNORE
(currently in beta), the scheduler will allow the job to exist within the
resource manager queue but will neither process it nor report it. MAIL will send email to both the admin and the user
when rejected jobs are detected. If RETRY is set, then Moab will allow the job to
remain idle and will only attempt to start the job when the policy violation is resolved.
Any combination of attributes may be
specified. (See QOSREJECTPOLICY.)
EXAMPLE
PARAMETER
JOBRETRYTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
60 seconds
DETAILS
Period of time Moab will continue to attempt to start a job which has failed to start due to transient failures or which has successfully started and was then rejected by the resource manager due to transient failures. See Reservation Policies and RESERVATIONRETRYTIME.
EXAMPLE
Moab will try for up to 5 minutes to restart jobs if the job start has failed due to transient errors.
PARAMETER
JOBSIZEPOLICY
FORMAT
<N/A>
DEFAULT
---
DETAILS
<N/A>
EXAMPLE
<N/A>
PARAMETER
JOBSYNCTIME
FORMAT
[[[DD:]HH:]MM:]:SS
DEFAULT
00:10:00
DETAILS
specifies the length of time after which Moab will synchronize a job's expected state with an unexpected reported state. IMPORTANT NOTE: Moab will not allow a job to run while its expected state does not match the state reported by the resource manager.
Moab will only maintain scheduler checkpoint information for jobs with explicitly modified job attributes. (some minor job performance and usage statistics may be lost)
Moab will only maintain scheduler checkpoint information for nodes with explicitly modified job attributes. (some minor node performance and usage statistics may be lost)
PARAMETER
LOADALLJOBCP
FORMAT
<BOOLEAN>
DEFAULT
FALSE
DETAILS
specifies whether Moab
should load, during startup, all non-completed jobs in the checkpoint
files regardless of whether or not
their corresponding resource managers are active. For example, this allows
source peers to continue showing remote jobs in the queue based on
checkpointed info, even though the destination peer is offline.
EXAMPLE
Moab will load, at startup, all non-completed jobs from all checkpoint files.
PARAMETER
LOGDIR
FORMAT
<STRING>
DEFAULT
log
DETAILS
specifies the directory in which log files will be maintained. If specified as a relative path, LOGDIR will be relative to $(MOABHOMEDIR) See Logging Overview for more information.
EXAMPLE
Moab will record its log files directly into the /var/spool/moab directory
PARAMETER
LOGFACILITY
FORMAT
colon delimited list of one or more of the following: fCORE, fSCHED, fSOCK, fUI, fLL, fCONFIG, fSTAT, fSIM, fSTRUCT, fFS, fCKPT, fBANK, fRM, fPBS, fWIKI, fALL
Moab will log only events involving general resource manager or PBS interface activities.
PARAMETER
LOGFILE
FORMAT
<STRING>
DEFAULT
moab.log
DETAILS
name of the Moab log file. This file is maintained in the directory pointed to by <LOGDIR> unless <LOGFILE> is an absolute path (see Logging Overview)
EXAMPLE
Log information will be written to the file moab.test.log located in the directory pointed to by the LOGDIR parameter
PARAMETER
LOGFILEMAXSIZE
FORMAT
<INTEGER>
DEFAULT
10000000
DETAILS
maximum allowed size (in bytes) the log file before it will be rolled (see Logging Overview)
EXAMPLE
Log files will be rolled when they reach 50 MB in size
PARAMETER
LOGFILEROLLDEPTH
FORMAT
<INTEGER>
DEFAULT
3
DETAILS
number of old log files to maintain (i.e., when full, moab.log will be renamed moab.log.1, moab.log.1 will be renamed moab.log.2, ... (see Logging Overview)
EXAMPLE
Moab will maintain and roll the last 5 log files.
PARAMETER
LOGLEVEL
FORMAT
<INTEGER> (0-9)
DEFAULT
0
DETAILS
specifies the verbosity of Moab logging where 9 is the most verbose (NOTE: each logging level is approximately an order of magnitude more verbose than the previous level) (see Logging Overview)
EXAMPLE
Moab will write all Moab log messages with a threshold of 4 or lower to the moab.log file
if set to NONE, no mail will be sent.
If set to DEFAULT, the default mail program, /usr/bin/sendmail, will be
used. NOTE: By default, Moab mail notification is disabled. To enable,
MAILPROGRAM must be set to DEFAULT or to the locally available mail program. If the default mail domain is set, emails will be routed to this domain unless a per-user domain is specified using the EMAILADDRESS attribute of the USERCFG parameter. (see Notify Admins)
EXAMPLE
PARAMETER
MAXJOB
FORMAT
<INTEGER>
DEFAULT
4096
DETAILS
specifies the maximum number of simultaneous
jobs which can be evaluated by the scheduler. If additional jobs are submitted to
the resource manager, Moab will ignore these jobs until previously submitted jobs
complete. NOTE: Moab must be restarted for any changes to this parameter to
take affect. The command mdiag -S will
indicate if any job overflows have occurred.
EXAMPLE
PARAMETER
MAXRSVPERNODE
FORMAT
<INTEGER>
DEFAULT
24
DETAILS
specifies the maximum number of reservations which can be on any single node. IMPORTANT NOTE: On large way SMP systems, this value often must be increased. To be on the safe side, this value should be approximately twice the average sum of admin, standing, and job reservations present. Moab must be restarted for any changes to this parameter to take affect. The command mdiag -S will indicate if any node reservation overflows have occurred. (see Considerations for Large Clusters)
EXAMPLE
PARAMETER
MEMREFRESHINTERVAL
FORMAT
[[[DD:]HH:]MM:]:SS | job:<COUNT>
DEFAULT
---
DETAILS
specifies the time interval or total job query count at which Moab will perform garbage collection to free memory associated with resource manager API's which possess memory leaks (i.e., Loadleveler, etc)
EXAMPLE
Moab will perform garbage collection once a day
PARAMETER
MEMWEIGHT
FORMAT
<INTEGER>
DEFAULT
0
DETAILS
specifies the coefficient to be multiplied by a job's MEM (dedicated memory in MB) factor. See Resource Priority Overview
EXAMPLE
each job's priority will be increased by 10 * 1000 * <request memory>
PARAMETER
MINADMINSTIME
FORMAT
<INTEGER>
DEFAULT
60 seconds
DETAILS
Specifies the minimum time a job will be suspended if suspended by an administrator or by a scheduler policy.
EXAMPLE
each job suspended by administrators or policies will stay in the suspended state for at least 10 minutes
specifies how Moab should allocate available resources to jobs.
See Node Allocation Overview for more information.
EXAMPLE
Moab will apply the node allocation policy MINRESOURCE to all jobs by default
PARAMETER
NODEALLOCRESFAILUREPOLICY
FORMAT
one of the following: CANCEL,
HOLD, IGNORE, MIGRATE, NOTIFY, or REQUEUE
DEFAULT
CANCEL
DETAILS
specifies how Moab should handle active jobs which experience node failures during execution. (see the RESFAILPOLICY resource manager extension or the Node Availability Overview).
EXAMPLE
Moab will requeue jobs which have allocated nodes fail during execution
PARAMETER
NODEAVAILABILITYPOLICY
FORMAT
<POLICY>[:<RESOURCETYPE>] ...
where
POLICY is one of COMBINED, DEDICATED, or UTILIZED
and
RESOURCETYPE is one of PROC, MEM, SWAP, or DISK
DEFAULT
COMBINED
DETAILS
specifies how Moab will evaluate node availability on a per resource basis. (See the Node Availability section of the Admin manual for more information)
EXAMPLE
Moab will ignore resource utilization information in locating available processors for jobs but will use both dedicated and utilized memory information in determining memory availability
PARAMETER
NODECATCREDLIST
FORMAT
<LABEL>=<NODECAT>[,<NODECAT>]...[ <LABEL>=<NODECAT>[,<NODECAT>]...]... where
<LABEL> is any string and <NODECAT> is one of the defined node categories.
DEFAULT
---
DETAILS
if specified, Moab will generate node category groupings and each iteration will assign usage of matching resources to pseudo-credentials with a name matching the specified label. (See
the Node Categorization section of the Admin manual for more information)
EXAMPLE
Moab will create a down user, group, account, class, and QoS and will associate BatchFailure, HardwareFailure, and NetworkFailure resources with these credentials. Additionally, Moab will assign all Idle resources to matching idle credentials.
specifies node-specific attributes for the node indicated in the array field. See the General Node Administration Overview for more information.
EXAMPLE
Moab will only allow two simultaneous jobs to run on node nodeA and will assign a relative machine speed of 1.2 to this node.
PARAMETER
NODEBUSYSTATEDELAYTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0:01:00 (one minute)
DETAILS
length of time Moab will assume busy nodes will remain unavailable for scheduling if a system reservation is not explicitly created for the node.
EXAMPLE
Moab will assume busy nodes are not available for scheduling for at least 30 minutes from the current time. Thus, these nodes will never be allocated to starting jobs. Also, these nodes will only be available for reservations starting more than 30 minutes in the future.
PARAMETER
NODEDOWNSTATEDELAYTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
1:00:00 (one hour)
DETAILS
length of time Moab will assume down, drained (offline), or corrupt nodes will remain unavailable for scheduling if a system reservation is not explicitly created for the node. See Node Availability for more information. Specifying "-1" will cause Moab to never create job reservations on down nodes.
EXAMPLE
Moab will assume down, drained, and corrupt nodes are not available for scheduling for at least 30 minutes from the current time. Thus, these nodes will never be allocated to starting jobs. Also, these nodes will only be available for reservations starting more than 30 minutes in the future.
PARAMETER
NODEDRAINSTATEDELAYTIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
3:00:00 (three hours)
DETAILS
length of time Moab will assume drained nodes will remain unavailable for scheduling if a system reservation is not explicitly created for the node. See Node Availability for more information.
EXAMPLE
Moab will assume down, drained, and corrupt nodes are not available for scheduling for at least 30 minutes from the current time. Thus, these nodes will never be allocated to starting jobs. Also, these nodes will only be available for reservations starting more than 30 minutes in the future.
PARAMETER
NODEFAILURERESERVETIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0:05:00
DETAILS
duration of reservation Moab will place on any node in which it detects a failure from the resource manager (0 indicates no reservation will be placed on the node). See Node Availability for more information. See also RMCFG[] NODEFAILURERSVPROFILE.
EXAMPLE
Moab will reserve failed nodes for 10:00
PARAMETER
NODEIDFORMAT
FORMAT
<STRING>
DEFAULT
*$N*
DETAILS
specifies how a node id can be processed to extract possible node, rack, slot, and cluster index information. The value of the parameter may include the markers '$C' (cluster index), '$N' (node index), '$R' (rack index), or '$S' (slot index) separated by '* (asterisk - representing any number of non-numeric characters) or other characters to indicate this encoding. See Node Selection for more information on use of node, rack, and slot indices.
EXAMPLE
Moab will extract rack and slot information from the cluster node ids (ie, tg-13s08)
PARAMETER
NODELOADPOLICY
FORMAT
one of the following: ADJUSTSTATE or ADJUSTPROCS
DEFAULT
ADJUSTSTATE
DETAILS
specifies whether a node's load affects its state or its available processors. The ADJUSTSTATE policy specifies that Moab should mark the node busy when the node's maximum load is reached. The ADJUSTPROCS policy causes the node's available procs to be equivalent to MIN(ConfiguredProcs - DedicatedProcs,MaxLoad - CurrentLoad) NOTE: NODELOADPOLICY only affects a node if MAXLOAD has been set.
EXAMPLE
Moab will mark a node busy if its measured load exceeds its maximum cpu load limit
PARAMETER
NODEMAXLOAD
FORMAT
<DOUBLE>
DEFAULT
0.0
DETAILS
specifies that maximum cpu load on a idle or running node. If the node's load reaches or exceeds this value, Moab will mark the node busy (See Load Balancing Features)
EXAMPLE
Moab will adjust the state of all idle and running nodes with a load >= .75 to the state busy
PARAMETER
NODEPOLLFREQUENCY
FORMAT
<INTEGER>
DEFAULT
0 (Poll Always)
DETAILS
specifies the number of scheduling iterations between scheduler initiated node manager queries. If set to '-2, Moab will never query the node manager daemons. If set to '-1', Moab will only query on the first iteration. NOTE: this parameter is most often used with OpenPBS and PBSPro. It is not required when using TORQUE, LoadLeveler, LSF, or SGE as the resource managers.
EXAMPLE
Moab will update node manager based information every 5 scheduling iterations
PARAMETER
NODEPURGETIME
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
--- (never purge node info)
DETAILS
The amount of time Moab will keep a node record which is no longer reported by the resource manager. Useful when using a resource manager which drops information about a node due to internal failures.
EXAMPLE
Moab will maintain a node record for 5 minutes after the last update regarding that object received from the resource manager.
PARAMETER
NODESETATTRIBUTE
FORMAT
one of ARCH, FEATURE, NETWORK, or PROCSPEED
DEFAULT
---
DETAILS
specifies the type of node attribute by which node set boundaries will be established.
(See Node Set Overview)
EXAMPLE
Moab will create node sets containing nodes with common processor speeds
PARAMETER
NODESETDELAY
FORMAT
[[[DD:]HH:]MM:]SS
DEFAULT
0:00:00
DETAILS
specifies the length of time Moab will delay
a job if adequate idle resources are available but are not available within node set constraints. Setting NODESETDELAY to any non-zero value will force Moab to always use nodesets. A value of zero will cause Moab to use nodesets on a best effort basis. NOTE: This attribute is deprecated - use NODESETISOPTIONAL instead. See Node Set Overview for more information.
EXAMPLE
Moab will create node sets containing nodes with common processor speeds. Moab will allocate resources within the nodeset if possible. If no resources exist within a single nodeset, Moab will attempt to run the job using any available resources.
PARAMETER
NODESETISOPTIONAL
FORMAT
<BOOLEAN>
DEFAULT
TRUE
DETAILS
specifies whether or not Moab will start a
job if a requested not set cannot be satisfied. (See Node Set Overview)
EXAMPLE
Moab will not block a job from running if its node set cannot be satisfied
