LSF Version 7.3 - Administering Platform LSF
Tuning LSF for Large Clusters
622 Administering Platform LSF
badmin hrestart restarts a new sbatchd. If a job process has already been
bound to a processor, after sbatchd is restarted, processor binding for the job
processes are restored.
◆ badmin reconfig
If the BIND_JOB parameter is modified in an application profile, badmin
reconfig
only affects pending jobs. The change does not affect running jobs.
◆ MultiCluster job forwarding model
In a MultiCluster environment, the behavior is similar to the current
application profile behavior. If the application profile name specified in the
submission cluster is not defined in the execution cluster, the job is rejected. If
the execution cluster has the same application profile name, but does not enable
processor binding, the job processes are not bound at the execution cluster.
Enable processor
binding for LSF job
processes
1 Enable processor binding cluster-wide or in an application profile.
❖ Cluster-wide configuration (lsf.conf)
Use LSF_BIND_JOB=Y in
lsf.conf to enable processor binding for all
execution hosts in the cluster. On the execution hosts that support this
feature, job processes will be hard bound to selected processors.
❖ Application profile configuration (lsb.applications)
Use BIND_JOB=Y in an application profile configuration in
lsb.applications to enable processor binding for all jobs submitted to
the application profile. On the execution hosts that support this feature, job
processes will be hard bound to selected processors.
If BIND_JOB is not set in an application profile in
lsb.applications, the
value of LSF_BIND_JOB in
lsf.conf takes effect. The BIND_JOB parameter
configured in an application profile overrides the lsf.conf setting.
Increasing the job ID limit
By default, LSF assigns job IDs up to 6 digits. This means that no more than 999999
jobs can be in the system at once. The job ID limit is the highest job ID that LSF will
ever assign, and also the maximum number of jobs in the system.
LSF assigns job IDs in sequence. When the job ID limit is reached, the count rolls
over, so the next job submitted gets job ID "1". If the original job 1 remains in the
system, LSF skips that number and assigns job ID "2", or the next available job ID.
If you have so many jobs in the system that the low job IDs are still in use when the
maximum job ID is assigned, jobs with sequential numbers could have different
submission times.
Increase the
maximum job ID
You cannot lower the job ID limit, but you can raise it to 10 digits. This allows
longer term job accounting and analysis, and means you can have more jobs in the
system, and the job ID numbers will roll over less often.
Use MAX_JOBID in
lsb.params to specify any integer from 999999 to
2147483646 (for practical purposes, you can use any 10-digit integer less than this
value).