You are here: 10.0 Managing Shared Resources - Usage Based Limits, Policies, and SMP Issues > Resource Usage Limits
|
|
10.3 Resource Usage Limits |
Resource usage limits constrain the amount of resources a given job may consume. These limits are generally proportional to the resources requested and may include walltime, any standard resource, or any specified generic resource. The parameter RESOURCELIMITPOLICY controls which resources are limited, what limit policy is enforced per resource, and what actions the scheduler should take in the event of a policy violation.
The RESOURCELIMITPOLICY parameter accepts a number of policies, resources, and actions using the format and values defined below.
If walltime is the resource to be limited, be sure that the resource manager is configured to not interfere if a job surpasses its given walltime. For TORQUE, this is done by using $ignwalltime in the configuration on each mom node. |
Format
RESOURCELIMITPOLICY<RESOURCE>:[<SPOLICY>,]<HPOLICY>:[<SACTION>,]<HACTION>[:[<SVIOLATIONTIME>,]<HVIOLATIONTIME>]...
Resource | Description | ||
---|---|---|---|
CPUTIME | Maximum total job proc-seconds used by any single job (allows scheduler enforcement of cpulimit). | ||
DISK | Local disk space (in MB) used by any single job task. | ||
JOBMEM | Maximum real memory/RAM (in MB) used by any single
job.
|
||
JOBPROC | Maximum processor load associated with any single job. | ||
MEM | Maximum real memory/RAM (in MB) used by any single job task. | ||
MINJOBPROC | Minimum processor load associated with any single job (action taken if job is using 5% or less of potential CPU usage). | ||
NETWORK | Maximum network load associated with any single job task. | ||
PROC | Maximum processor load associated with any single job task. | ||
SWAP | Maximum virtual memory/SWAP (in MB) used by any single job task. | ||
WALLTIME | Requested job walltime. |
Policy | Description |
---|---|
ALWAYS | take action whenever a violation is detected |
EXTENDEDVIOLATION | take action only if a violation is detected and persists for greater than the specified time limit |
BLOCKEDWORKLOADONLY | take action only if a violation is detected and the constrained resource is required by another job |
Action | Description |
---|---|
CANCEL | terminate the job |
CHECKPOINT | checkpoint and terminate job |
MIGRATE | requeue the job and require a different set of hosts for execution |
NOTIFY | notify admins and job owner regarding violation |
REQUEUE | terminate and requeue the job |
SUSPEND | suspend the job and leave it suspended for an amount of time defined by the X parameter |
Example - Notify and then cancel job if requested memory is exceeded
# if job exceeds memory usage, immediately notify owner # if job exceeds memory usage for more than 5 minutes, cancel the job RESOURCELIMITPOLICY MEM:ALWAYS,EXTENDEDVIOLATION:NOTIFY,CANCEL:00:05:00
Example - Checkpoint job on walltime violations
# if job exceeds requested walltime, checkpoint job RESOURCELIMITPOLICY WALLTIME:ALWAYS:CHECKPOINT # when checkpointing, send term signal, followed by kill 1 minute later RMCFG[base] TYPE=PBS CHECKPOINTTIMEOUT=00:01:00 CHECKPOINTSIG=SIGTERM
Example - Cancel jobs that use 5% or less of potential CPU usage for more than 5 minutes
RESOURCELIMITPOLICY MINJOBPROC:EXTENDEDVIOLATION:CANCEL:5:00
Example - Migrating a job when it blocks other workload
RESOURCELIMITPOLICY JOBPROC:BLOCKEDWORKLOADONLY:MIGRATE
Moab is able to perform different actions for both hard and soft policy violations. In most resource management systems, a mechanism does not exist to allow the user to specify both hard and soft limits. To address this, Moab provides the RESOURCELIMITMULTIPLIER parameter that allows per partition and per resource multiplier factors to be specified to generate the actual hard and soft limits to be used. If the factor is less than one, the soft limit will be lower than the specified value and a Moab action will be taken before the specified limit is reached. If the factor is greater than one, the hard limit will be set higher than the specified limit allowing a buffer space before the hard limit action is taken.
In the following example, job owners will be notified by email when their memory reaches 100% of the target, and the job will be canceled if it reaches 125% of the target. For wallclock usage, the job will be requeued when it reaches 90% of the specified limit if another job is waiting for its resources, and it will be checkpointed when it reaches the full limit.
RESOURCELIMITPOLICY MEM:ALWAYS,ALWAYS:NOTIFY,CANCEL RESOURCELIMITPOLICY WALLTIME:BLOCKEDWORKLOADONLY,ALWAYS:REQUEUE,CHECKPOINT RESOURCELIMITMULTIPLIER MEM:1.25,WALLTIME:0.9
While Moab constrains walltime using the parameter RESOURCELIMITPOLICY like other resources, it also allows walltime exception policies which are not available with other resources. In particular, Moab allows jobs to exceed the requested wallclock limit by an amount specified on a global basis using the JOBMAXOVERRUN parameter or on a per credential basis using the OVERRUN attribute of the *CFG credential parameters.
JOBMAXOVERRUN 00:10:00 CLASSCFG[debug] overrun=00:00:30
Copyright © 2012 Adaptive Computing Enterprises, Inc.®