LSF Version 7.3 - Administering Platform LSF

Administering Platform LSF 397
Resource Allocation Limits
825 user1 RUN normal hostA hostA sleep 1000 Jan 22 16:38
826 user1 RUN normal hostA hostA sleep 1000 Jan 22 16:38
827 user1 PEND normal hostA sleep 1000 Jan 22 16:38
Only one job (827) remains pending because the more restrictive limit of 3 in
lsb.resources is enforced:
bjobs -p
JOBID USER STAT QUEUE FROM_HOST JOB_NAME SUBMIT_TIME
827 user1 PEND normal hostA sleep 1000 Jan 22 16:38
Resource (slot) limit defined cluster-wide has been reached;
Equivalent conflicting limits
New limits in lsb.resources that are equivalent to existing limits in lsb.users,
lsb.hosts, or lsb.queues, but with a different value override the existing limits.
The equivalent limits in
lsb.users, lsb.hosts, or lsb.queues are ignored, and
the value of the new limit in
lsb.resources is used.
For example, a per-user job slot limit in
lsb.resources is equivalent to a
MAX_JOBS limit in
lsb.users, so only the lsb.resources limit is enforced, the
limit in
lsb.users is ignored:
Begin Limit
NAME = slot_limit
PER_USER =all
SLOTS = 3
End Limit
How job limits work
The JOBS parameter limits the maximum number of running or suspended jobs
available to resource consumers. Limits are enforced depending on the number of
jobs in RUN, SSUSP, and USUSP state.
Stopping and
resuming jobs
Jobs stopped with bstop, go into USUSP status. LSF includes USUSP jobs in the
count of running jobs, so the usage of JOBS limit will not change when you suspend
a job.
Resuming a stopped job (
bresume) changes job status to SSUSP. The job can enter
RUN state, if the JOBS limit has not been exceeded. Lowering the JOBS limit before
resuming the job can exceed the JOBS limit, and prevent SSUSP jobs from entering
RUN state.
For example, JOBS=5, and 5 jobs are running in the cluster (JOBS has reached 5/5).
Normally. the stopped job (in USUSP state) can later be resumed and begin
running, returning to RUN state. If you reconfigre the JOBS limit to 4 before
resuming the job, the JOBS usage becomes 5/4, and the job cannot run because the
JOBS limit has been exceeded.
Preemption The JOBS limit does not block preemption based on job slots. For example, if
JOBS=2, and a host is already running 2 jobs in a preemptable queue, a new
preemptive job can preempt a job on that host as long as the preemptive slots can
be satisfied even though the JOBS limit has been reached.