Resource usage limits control how much resource can be consumed by running jobs. Jobs that use more than the specified amount of a resource are signalled or have their priority lowered.
Limits can be specified by the LSF administrator:
At the queue level in lsb.queues
In an application profile in lsb.applications
At the job level when you submit a job
For example, by defining a high-priority short queue, you can allow short jobs to be scheduled earlier than long jobs. To prevent some users from submitting long jobs to this short queue, you can set CPU limit for the queue so that no jobs submitted from the queue can run for longer than that limit.
Limits specified at the queue level are hard limits, while those specified with job submission or in an application profile are soft limits. The hard limit acts as a ceiling for the soft limit. See setrlimit(2) man page for concepts of hard and soft limits.
This chapter describes queue-level and job-level resource usage limits. Priority of limits is different if limits are also configured in an application profile.
Resource usage limits are not the same as resource allocation limits, which are enforced during job scheduling and before jobs are dispatched. You set resource allocation limits to restrict the amount of a given resource that must be available during job scheduling for different classes of jobs to start, and to which resource consumers the limits apply.
Resource usage limits are not the same as queue-based resource reservation limits, which are enforced during job submission. The parameter RESRSV_LIMIT (in lsb.queues) specifies allowed ranges of resource values, and jobs submitted with resource requests outside of this range are rejected.
Limit |
Job syntax (bsub) |
Syntax (lsb.queues and lsb.applications) |
Format/Default Units |
---|---|---|---|
Core file size limit |
-C core_limit |
CORELIMIT=limit |
integer KB |
CPU time limit |
-c cpu_limit |
CPULIMIT=[default] maximum |
[hours:]minutes[/host_name | /host_model] |
Data segment size limit |
-D data_limit |
DATALIMIT=[default] maximum |
integer KB |
File size limit |
-F file_limit |
FILELIMIT=limit |
integer KB |
Memory limit |
-M mem_limit |
MEMLIMIT=[default] maximum |
integer KB |
Process limit |
-p process_limit |
PROCESSLIMIT=[default] maximum |
integer |
Run time limit |
-W run_limit |
RUNLIMIT=[default] maximum |
[hours:]minutes[/host_name | /host_model] |
Stack segment size limit |
-S stack_limit |
STACKLIMIT=limit |
integer KB |
Virtual memory limit |
-v swap_limit |
SWAPLIMIT=limit |
integer KB |
Thread limit |
-T thread_limit |
THREADLIMIT=[default] maximum |
integer |
If ... |
Then ... |
---|---|
Both default and maximum limits are defined |
The default is enforced |
Only a maximum is defined |
The maximum is enforced |
No limit is specified in the queue or at job submission |
No limits are enforced |
Incorrect limits are ignored, and a warning message is displayed when the cluster is reconfigured or restarted. A warning message is also logged to the mbatchd log file when LSF is started.
If ... |
Then ... |
---|---|
The default limit is not correct |
The default is ignored and the maximum limit is enforced |
Both default and maximum limits are specified, and the maximum is not correct |
The maximum is ignored and the resource has no maximum limit, only a default limit |
Both default and maximum limits are not correct |
The default and maximum are ignored and no limit is enforced |
Resource usage limits specified at job submission must be less than the maximum specified in lsb.queues. The job submission is rejected if the user-specified limit is greater than the queue-level maximum, and the following message is issued:
Cannot exceed queue’s hard limit(s). Job not submitted.