LSF 基本使用¶
LSF（Load Sharing Facility）是IBM旗下的一款分布式集群管理系统软件，负责计算资源的管理和批处理作业的调度。它给用户提供统一的集群资源访问接口，让用户透明地访问整个集群资源。同时提供了丰富的功能和可定制的策略。LSF 具有良好的可伸缩性和高可用性，支持几乎所有的主流操作系统。它通常是高性能计算环境中不可或缺的基础软件。
LSF的功能和命令非常多，这里主要介绍普通用户常用命令，更详细的命令文档参见 IBM Spectrum LSF command reference。
提交作业¶
LSF命令行提交作业¶
与PBS不同，大部分情况下，可以不需要写作业脚本，直接一行命令就可以提交作业
bsub -J blast -n 10 -R span[hosts=1] -o %J.out -e %J.err -q normal "blastn -query ./ZS97_cds.fa -out ZS97_cds -db ./MH63_cds -outfmt 6 -evalue 1e-5 -num_threads \$LSB_DJOB_NUMPROC"
LSF脚本1-串行作业(单节点)¶
LSF中用户运行作业的主要方式为，编写LSF作业脚本，使用bsub命令提交作业脚本。如下所示为使用LSF脚本blastn.lsf
#BSUB -J blast
#BSUB -n 10
#BSUB -R span[hosts=1]
#BSUB -o %J.out
#BSUB -e %J.err
#BSUB -q normal
# 注意-num_threads是blastn的线程设置参数，不同软件参数不同
# 如果软件没有明确有设置线程数的参数，则不设置，默认使用单线程，作业也只需申请一个CPU核心
blastn -query ./ZS97_cds.fa -out ZS97_cds -db ./MH63_cds -outfmt 6 -evalue 1e-5 -num_threads $LSB_DJOB_NUMPROC
提交作业blastn.lsf
bsub < blastn.lsf
脚本中每行内容解释
- -J 指定作业名称
- -n 作业使用核心数，LSF中一般称之为slot
- -R span[hosts=1] 指定作业只能在单个节点运行，不能跨节点（跨节点作业需要MPI支持，生物中比较少）。-R 可以使得作业在需要满足某种条件的节点上运行，常用的有
-R "rusage[mem=20GB]"，表示作业预计消耗的内存为20G，节点需要为作业预留20G内存，消耗内存较大的作业需要合理设置该选项，以避免多个作业挤在一个节点而导致节点因内存耗尽而挂掉，内存也不可写得太大，否则会导致大量节点因为要预留很多内存，而不能接收新的作业，造成资源浪费；-R "select[maxmem>224800]"，表示选择节点物理内存大于224800MB的节点来运行当前作业，需要使用大内存节点时，可以使用此选项。多个-R 选项可以组合，如-R "span[hosts=1] rusage[mem=20GB] select[maxmem>224800]"。 - -o 作业标准输出，%J为作业ID，即此处的作业输出文件为 jobid.out
- -e 作业错误输出，%J为作业ID，即此处的作业输出文件为 jobid.err
- -q 作业提交的作业队列
Note
$LSB_DJOB_NUMPROC 为LSF系统变量，表示作业脚本申请的CPU核心数。建议所有作业都使用这个变量设置程序使用的线程数，方便动态调整以及作业脚本申请的核心数和程序设置的线程数保持一致。如blastn使用-num_threads这个参数设置线程数，LSF脚本申请4核用多线程跑时，一般写法为blastn -num_threads 4，LSF脚本内的推荐写法为：用$LSB_DJOB_NUMPROC变量代替4，即 blastn -num_threads $LSB_DJOB_NUMPROC，这样调整LSF -n参数申请不同的核数时，-num_threads 参数可以不用同步调整。
另外还有一些常用选项
- -M 内存控制参数，作业占用的内存超过其指定值时，作业会被系统杀掉。如
-M 20GB -R "rusage[mem=20GB]"申请20GB的内存，且其内存使用量不能超过20G - -m 指定作业运行节点，如
-m c01n01 - -W hh:mm 设置作业运行时间
- -w 作业依赖，方便写流程，如
-w "done(JobA)"，作业名为JobA的作业完成之后，该作业才开始运行；作业依赖详细用法 - -K 提交作业并等待作业结束，在写流程时会用得上，可以见后面的例子
- -P 指定project name，如果我们需要统计某个项目消耗的计算资源，如CPU时等，可以将相关的作业都指定为同一个project name，然后根据project name统计资源消耗
- -r rerun选项，即作业失败后自动重新运行，提交大量作业时此选项比较有用
LSF脚本2-并行作业(多节点)¶
#BSUB -J MPIJob ### set the job Name
#BSUB -q normal ### specify queue
#BSUB -n 400 ### ask for number of cores (default: 1)
#BSUB -R "span[ptile=20]" ### ask for 20 cores per node
#BSUB -W 10:00 ### set walltime limit: hh:mm
#BSUB -o stdout_%J.out ### Specify the output and error file. %J is the job-id
#BSUB -e stderr_%J.err ### -o and -e mean append, -oo and -eo mean overwrite
# here follow the commands you want to execute
# load the necessary modules
# NOTE: this is just an example, check with the available modules
module load intel/2018.4
module load mpi/intel/2018.4
### This uses the LSB_DJOB_NUMPROC to assign all the cores reserved
### This is a very basic syntax. For more complex examples, see the documentation
mpirun -np $LSB_DJOB_NUMPROC ./MPI_program
此脚本申请400核，每个节点20个核。
多节点并行作业需要程序本身支持，使用mpirun等MPI命令运行，绝大部分生物软件不支持多节点并行。强行使用，会出现作业申请了并占用了多个节点，但程序实际只使用了一个节点，其它节点无程序运行，造成资源的极大浪费 。如不确定程序是否支持多节点并行，请勿使用，避免资源浪费。
使用系统范围的intelmpi / openmpi时，可以省略-np $ LSB_DJOB_NUMPROC命令，因为程序会自动获取有关核心总数的信息。如果使用不同的MPI库，可能需要明确指定MPI的数量 以这种方式在命令行上进行处理。
LSF批量提交作业¶
批量提交简单作业¶
需要处理的数据样本较多时，手工提交非常繁琐，且容易出错，我们可以编写简单的shell脚本来实现大批量自动提交多个作业（可同时提交上万个作业）。
以跑多样本的STAR为例，将下面的脚本保存为run_STAR.sh，运行该脚本，即可同时提交一批作业，而不用一个个手动提交。
for sample in /public/home/username/work/lsf_bwait/raw_data/*trim_1.fq.gz;do
index=$(basename $sample |sed 's/_trim_1.fq.gz//')
prefix=$(dirname $sample)
star_index=/public/home/username/work/lsf_bwait/star/
gtf=/public/home/username/work/lsf_bwait/MH63.gtf
bsub -J ${index} -n 8 -o %J.${index}.out -e %J.${index}.err -R span[hosts=1] \
"STAR --runThreadN 8 --genomeDir ${star_index} --readFilesIn ${prefix}/${index}_trim_1.fq.gz ${prefix}/${index}_trim_2.fq.gz --outFileNamePrefix ${index}. --sjdbGTFfile $gtf"
sleep 10
done
批量提交分析流程¶
生信中经常会遇到需要跑大量作业以及复杂流程的情况，特别是当流程中使用的软件为多线程和单线程混杂时，如果把所有流程步骤写到同一个shell脚本，并按多线程需要的线程数来申请CPU 核心数，无疑会造成比较大的浪费。
在此建议将流程中的主要运行步骤直接用bsub提交，按需要申请核心数、内存等，需要用上文中提到的bsub的 -K 参数。这里写了一个跑RNA-Seq流程的example，主要是2个脚本，RNA.sh 为具体处理每个样本的流程脚本，在batch_run.sh 对每个样本都提交运行RNA.sh脚本。
使用时，提交batch_run.lsf脚本即可, bsub < batch_run.lsf 。
RNA.sh
#!/bin/sh
sample=$1
index=$(basename $sample |sed 's/_trim_1.fq.gz//')
prefix=$(dirname $sample)
star_index=/public/home/username/work/lsf_bwait/star/
gtf=/public/home/username/work/lsf_bwait/MH63.gtf
bsub -K -J STAR1 -n 8 -o %J.STAR1.out -e %J.STAR1.err -R span[hosts=1] "module purge;module load STAR/2.6.0a-foss-2016b;STAR --runThreadN 8 --genomeDir ${star_index} \
--readFilesIn ${prefix}/${index}_trim_1.fq.gz ${prefix}/${index}_trim_2.fq.gz \
--outSAMtype SAM --readFilesCommand zcat --alignIntronMax 50000 --outFileNamePrefix ${index}. --sjdbGTFfile $gtf --outReadsUnmapped None"
bsub -K -J STAR2 -n 1 -o %J.STAR2.out -e %J.STAR2.err -R span[hosts=1] "grep -E '@|NH:i:1' ${index}.Aligned.out.sam >${index}.Aligned.out.uniq.sam"
bsub -K -J STAR3 -n 2 -o %J.STAR3.out -e %J.STAR3.err -R span[hosts=1] "module purge;module load SAMtools/1.3;samtools sort -@2 ${index}.Aligned.out.uniq.sam > ${index}.Aligned.out.bam"
rm ${index}.Aligned.out.sam
rm ${index}.Aligned.out.uniq.sam
rm ${index}.Aligned.out.uniq.bam
bsub -K -J STAR4 -n 1 -o %J.STAR4.out -e %J.STAR4.err -R span[hosts=1] "module purge;module load HTSeq/0.8.0;htseq-count -f bam -s no ${index}.Aligned.out.bam -t gene $gtf >${index}.Genecounts 2>${index}.htseq.log"
batch_run.lsf
#BSUB -J STAR
#BSUB -n 1
#BSUB -R span[hosts=1]
#BSUB -o %J.out
#BSUB -e %J.err
for sample in /public/home/username/work/lsf_bwait/raw_data/*trim_1.fq.gz;do
index=$(basename $sample |sed 's/_trim_1.fq.gz//')
sh RNA.sh ${sample} &
sleep 10
done
wait
不合理批量提交方式¶
如下这个脚本所示，在一个lsf脚本内循环跑多个样本，即一个样本跑完之后才能跑下一个，每个样本的运行时间较长，这样不能充分利用集群节点多、核多的优势，比较浪费时间，因此如果不是有特殊需求，不建议使用这种方式跑多个样本的作业。
#BSUB -J STAR
#BSUB -n 8
#BSUB -R span[hosts=1]
#BSUB -o %J.out
#BSUB -e %J.err
for sample in /public/home/username/work/lsf_bwait/raw_data/*trim_1.fq.gz;do
index=$(basename $sample |sed 's/_trim_1.fq.gz//')
prefix=$(dirname $sample)
star_index=/public/home/username/work/lsf_bwait/star/
gtf=/public/home/username/work/lsf_bwait/MH63.gtf
STAR --runThreadN 8 --genomeDir ${star_index} --readFilesIn ${prefix}/${index}_trim_1.fq.gz ${prefix}/${index}_trim_2.fq.gz --outFileNamePrefix ${index}. --sjdbGTFfile $gtf"
sleep 10
done
大批量小作业提交¶
由于作业排队调度和退出需要一定时间，如果每个作业内程序运行时间很短(小于10min)、且作业数量较大(大于1000)，建议将多个作业合并在一个作业内运行。
如下所示，需要提交1000个不同参数的作业，可以每个作业内跑100个作业，提交10这样的作业：
#BSUB -J process1-100
#BSUB -n 1
#BSUB -R span[hosts=1]
#BSUB -o %J.out
#BSUB -e %J.err
for args in {args1,args2..args100};do
python process.py ${args}
done
合理设置作业内存¶
对于部分程序，因其使用的核数较少、单个作业内存消耗较大，直接批量提交时，容易多个作业被系统分配在一个节点，导致节点内存耗尽、作业被挂起的情况。
跑GWAS流程时所用的一些软件比较频繁出现这种情况，如fastlmmc tassel。因此需要先跑一个作业，结束后查看内存使用(maxmem)，如15G，然后批量提交使用lsf参数 -R rusage[mem=15G]来申请内存。
同时不建议盲目申请远远超出实际使用的内存量，如-R rusage[mem=100G]，这会导致一个节点只会运行2-3个作业，其它作业也无法使用该节点，造成计算资源大量浪费。
单个作业使用的核心数低于4时，需要及时关注作业运行情况，如果出现大量作业被挂起的情况，使用lsload查看节点内存剩余情况，bjobs -l jobid查看作业内存使用量，使用bmod -R "rusage[mem=15GB] select[maxmem>224800]" jobid调整作业内存消耗，然后brequeue jobid重新运行该作业。
多次出现作业被大面积挂起的情况且没有及时处理，将被降低可使用的核数。
LSF交互作业¶
类似于PBS中的qsub -I，为了防止滥用（开了之后长期不关等）交互模式，目前只允许在interactive队列使用交互模式，且时间限制为48h，超时会被杀掉。
bsub -q interactive -Is bash
也可以
bsub -q interactive -Is sh
此时不会加载~/.bashrc
如果需要进行图形转发，如画图等，可以加-XF 参数
bsub -q interactive -XF -Is bash
查询作业¶
使用bjobs命令查看作业运行状态、所在队列、从哪个节点提交、运行节点及核心数、作业名称、提交时间等。
$ bjobs
JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
10498205 username RUN smp login01 10*s001 fq Sep 6 17:54
10498206 username RUN smp login01 10*s001 fq Sep 6 17:54
10498207 username RUN smp login01 10*s001 fq Sep 6 17:54
10498209 username RUN smp login01 10*s001 fq Sep 6 17:54
10498211 username RUN smp login01 10*s001 fq Sep 6 17:54
10498217 username RUN smp login01 10*s001 fq Sep 6 17:54
10498219 username RUN smp login01 10*s001 fq Sep 6 17:54
10498226 username RUN smp login01 10*s001 fq Sep 6 17:54
10498227 username RUN smp login01 10*s001 fq Sep 6 17:54
10498708 username PEND smp login01 fq Sep 6 17:54
10498709 username PEND smp login01 fq Sep 6 17:54
10498710 username PEND smp login01 fq Sep 6 17:54
10498711 username PEND normal login01 fq Sep 6 17:54
10498712 username PEND normal login01 fq Sep 6 17:54
10559750 username USUSP high login02 2*c03n07 GWA Sep 7 14:30
作业状态主要有:
- PEND 正在排队
- RUN 正在运行
- DONE 正常退出
- EXIT 异常退出
- SSUSP 被系统挂起
- USUSP 被用户自己挂起
bjobs还有一些常用的选项，
- -r 查看正在运行的作业
- -pe 查看排队作业
- -l 查看作业详细信息
- -sum 查看所有未完成作业的汇总信息
- -p 查看作业排队的原因，如下面这个作业的排队原因为用户所有正在运行作业所使用的总核心数达到了该用户所能使用核心数上限 其它相关提示如下：
$ bjobs -p 40482594 JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 10482594 username PEND normal c01n05 bwa Sep 6 06:33 The user has reached his/her job slot limit (Limit Name: N/A, Limit Value: 1200);User has reached the pre-user job slot limit of the queue
: 用户作业达到了排队中作业所在队列的个人作业核数上限。 : 此队列中用户正在运行的作业有计算结束后，才会再分配后续的排队作业。The slot limit reached;4 hosts: 排队中作业数达到了所在队列可使用节点数的上限。 : 此队列中所有用户正在运行的作业有计算结束，才会再分配此队列中排在最前边的作业。The user has reached his job slot limit: 用于已运行的作业数达到了系统规定的上限。 : 需已运行的作业有新的计算结束，排队中的作业才会进入调度系统。The queue has reached its job slot limit: 排队中已经运行的所有作业达到了系统上队列总作业核数的上限。 : 需该队列中已经运行的作业有新的计算结束，才会调度该队列中排在第一位的作业。Pending job threshold reached. Retrying in 60 seconds: 提交的作业超过系统对用户提交作业数的上限。 : 需该队列中已经运行的作业有新的计算结束，新提交的作业才会被LSF接收。
-o 定制输出格式，如为了方便实时查看作业使用的最大内存，添加
max_mem选项，宽度为14。使用$ bjobs -o "jobid:10 user:6 stat:6 queue:6 exec_host:10 job_name:10 max_mem:14 submit_time:12" JOBID USER STAT QUEUE EXEC_HOST JOB_NAME MAX_MEM SUBMIT_TIME 46477783 username RUN high c01n09 AS_TWAS 30.3 Gbytes Dec 12 13:32 46477903 username RUN high c01n09 AS_TWAS 22.6 Gbytes Dec 12 13:32 46477766 username RUN high c01n09 AS_TWAS 20.3 Gbytes Dec 12 13:32 46477725 username RUN high c01n05 AS_TWAS 26.5 Gbytes Dec 12 13:32 46477726 username RUN high c01n05 AS_TWAS 22.7 Gbytes Dec 12 13:32 46477727 username RUN high c01n05 AS_TWAS 19.2 Gbytes Dec 12 13:32 46477804 username RUN high c01n05 AS_TWAS 26.6 Gbytes Dec 12 13:32 46477805 username RUN high c01n05 AS_TWAS 20.3 Gbytes Dec 12 13:32 46477836 username RUN high c01n04 AS_TWAS 25.2 Gbytes Dec 12 13:32alias简写该命令此外也可以添加$ vim ~/.bashrc alias bbjobs='bjobs -o "jobid:10 user:6 stat:6 queue:6 exec_host:10 job_name:10 max_mem:14 submit_time:12"' $ source ~/.bashrc $ bbjobs JOBID USER STAT QUEUE EXEC_HOST JOB_NAME MAX_MEM SUBMIT_TIME 46477783 username RUN high c01n09 AS_TWAS 30.3 Gbytes Dec 12 13:32 46477903 username RUN high c01n09 AS_TWAS 22.6 Gbytes Dec 12 13:32 46477766 username RUN high c01n09 AS_TWAS 20.3 Gbytes Dec 12 13:32 46477725 username RUN high c01n05 AS_TWAS 26.5 Gbytes Dec 12 13:32 46477726 username RUN high c01n05 AS_TWAS 22.7 Gbytes Dec 12 13:32 46477727 username RUN high c01n05 AS_TWAS 19.2 Gbytes Dec 12 13:32 46477804 username RUN high c01n05 AS_TWAS 26.6 Gbytes Dec 12 13:32 46477805 username RUN high c01n05 AS_TWAS 20.3 Gbytes Dec 12 13:32 46477836 username RUN high c01n04 AS_TWAS 25.2 Gbytes Dec 12 13:32run_timecpu_used查询作业的 runtime (作业运行的时间)和 cputime (作业运行消耗的CPU时)。一般而言，cputime ≈ runtime*核数，若 cputime 远小于 runtime，则表示作业资源申请不合理，或作业在空跑，请检查作业是否正常在跑。 如下所示，作业 cputime 远小于 runtime，经检查作业运行出错，但没有退出。alias bbs='bjobs -o "jobid:8 user:8 stat:6 queue:6 exec_host:10 job_name:8 nreq_slot:6 slots:5 max_mem:12 submit_time:12 start_time:12 run_time:16 cpu_used"'# bjobs -o "jobid:8 user:8 stat:6 queue:6 exec_host:10 job_name:8 nreq_slot:6 slots:5 max_mem:12 submit_time:12 start_time:12 run_time:16 cpu_used" $ bbs JOBID USER STAT QUEUE EXEC_HOST JOB_NAME NREQ_S SLOTS MAX_MEM SUBMIT_TIME START_TIME RUN_TIME CPU_USED 6554018 username RUN normal 8*c03n02 *g_BK200 8 8 520 Mbytes Sep 13 15:38 Sep 13 20:28 48509 second(s) 3285 second(s) 6554039 username RUN normal 8*c03n06 *g_BR461 8 8 473 Mbytes Sep 13 15:38 Sep 13 21:18 45488 second(s) 4043 second(s) 6554029 username RUN normal 8*c03n09 *g_BL300 8 8 517 Mbytes Sep 13 15:38 Sep 13 21:09 46049 second(s) 4067 second(s) 6554015 username RUN normal 8*c01n05 *_BJS500 8 8 516 Mbytes Sep 13 15:38 Sep 13 20:20 48979 second(s) 3222 second(s) 6554021 username RUN normal 8*c02n09 *g_BK350 8 8 482 Mbytes Sep 13 15:38 Sep 13 20:32 48232 second(s) 2963 second(s) 6554022 username RUN normal 8*c02n08 *g_BK400 8 8 699 Mbytes Sep 13 15:38 Sep 13 20:37 47988 second(s) 3952 second(s) 6554028 username RUN normal 8*c03n01 *g_BL250 8 8 539 Mbytes Sep 13 15:38 Sep 13 21:03 46410 second(s) 3755 second(s) 6554024 username RUN normal 8*c04n03 *g_BK500 8 8 515 Mbytes Sep 13 15:38 Sep 13 20:38 47873 second(s) 3867 second(s) 6554044 username RUN normal 8*c01n13 *g_BS400 8 8 507 Mbytes Sep 13 15:38 Sep 13 21:23 45191 second(s) 2018 second(s) 6554043 username RUN normal 8*c01n02 *g_BS300 8 8 593 Mbytes Sep 13 15:38 Sep 13 21:23 45221 second(s) 3394 second(s) 6554046 username RUN normal 8*c02n10 *g_BS500 8 8 534 Mbytes Sep 13 15:38 Sep 13 21:28 44888 second(s) 3262 second(s)
修改排队作业运行参数¶
bmod可更改正在排队的作业的多个参数，如
bmod -n 2 jobid 更改作业申请的核心数
bmod -q q2680v2 jobid 更改作业运行队列
挂起/恢复作业¶
用户可自行挂起或者继续运行被挂起的作业。
bstop jobid 挂起作业，如作业被系统挂起（节点剩余可用内存过低系统会自动挂起该节点上的部分作业），则作业状态为SSUSP；如被用户自己或管理员挂起，则作业状态为USUSP
bresume bjoid 继续运行被挂起的作业
因为作业在挂起时，仍然会占用计算资源，因此用户不可自己随意长时间大批量挂起自己的作业以避免资源浪费。
调整排队作业顺序¶
bbot jobid 将排队的作业移动到队列最后（bottom）
btop jobid 将排队的作业移动到队列最前（top）
查询输出文件¶
在作业完成之前，输出文件out和error被保存在系统文件中无法查看，可以使用bpeek命令查看输出文件
终止作业¶
如果用户要在作业提交后终止自己的作业，可以使用bkill命令，用法为bkill jobid。非root用户只能查看、删除自己提交的作业。
bkill 12345 杀死作业id为12345的作业
bkill 0 杀死当前用户的所有作业(正在运行的、排队的、挂起的等)
资源查看¶
bhosts¶
查看所有节点核心数使用情况
$ bhosts
HOST_NAME STATUS JL/U MAX NJOBS RUN SSUSP USUSP RSV
c01n01 closed - 36 36 36 0 0 0
c01n02 closed - 36 36 36 0 0 0
c01n03 closed - 36 36 36 0 0 0
c01n04 closed - 36 36 36 0 0 0
c01n05 closed - 36 36 36 0 0 0
c07n09 closed - 36 36 36 0 0 0
c07n10 closed - 36 36 36 0 0 0
c07n11 closed - 36 36 36 0 0 0
gpu01 ok - 36 29 29 0 0 0
gpu02 ok - 20 0 0 0 0 0
login01 closed - 0 0 0 0 0 0
login02 closed - 0 0 0 0 0 0
login03 closed - 0 0 0 0 0 0
mn02 closed - 0 0 0 0 0 0
mn02 closed - 0 0 0 0 0 0
s001 closed - 192 192 192 0 0 0
s002 closed - 192 192 192 0 0 0
s003 ok - 192 189 189 0 0 0
sg01 closed - 20 20 20 0 0 0
sg02 closed - 20 20 20 0 0 0
sg03 closed - 20 20 20 0 0 0
sg04 closed - 20 20 20 0 0 0
sg05 closed - 20 20 20 0 0 0
sg06 ok - 20 0 0 0 0 0
sg07 closed - 20 20 20 0 0 0
sg08 closed - 20 20 20 0 0 0
sg09 ok - 20 0 0 0 0 0
sg10 ok - 20 17 17 0 0 0
- HOST_NAME 节点名称
- STATUS： ok：表示可以接收新作业，只有这种状态可以接受新作业 closed：表示已被作业占满，不接受新作业 unavail和unreach：系统停机或作业调度系统服务有问题
- JL/U 每个用户在该节点最多能使用的核数，- 表示没有限制
- MAX 最大可以同时运行的核数
- NJOBS 当前所有运行和待运行作业所需的核数
- RUN 已经开始运行的作业占据的核数
- SSUSP 系统所挂起的作业所使用的核数
- USUSP 用户自行挂起的作业所使用的核数
- RSV 系统为你预约所保留的核数
lsload¶
查看所有节点的负载、内存使用等
$ lsload
HOST_NAME status r15s r1m r15m ut pg ls it tmp swp mem
sg17 ok 0.0 0.0 0.1 0% 0.0 0 2e+5 264G 2.4G 113G
sg11 ok 0.0 0.0 0.1 0% 0.0 0 49055 264G 3.7G 113G
gpu02 ok 0.0 0.0 0.1 0% 0.0 0 7337 248G 29.8G 52.9G
login01 ok 0.2 0.7 0.6 6% 0.0 39 0 242G 0M 47.6G
login02 ok 0.7 0.4 0.6 5% 0.0 41 0 241G 27.8G 42.9G
sg27 ok 0.8 0.6 0.6 4% 0.0 0 88098 264G 3G 110G
c01n11 ok 0.8 19.7 19.6 4% 0.0 0 1788 432G 2.1G 348G
c05n07 ok 1.0 1.0 1.0 3% 0.0 0 1463 429G 3G 170G
c07n09 ok 1.0 1.0 1.0 3% 0.0 0 14604 432G 3.9G 158G
c01n10 ok 1.1 18.7 18.7 3% 0.0 0 3713 432G 3G 349G
sg21 ok 1.2 1.2 1.2 7% 0.0 0 5054 258G 3.6G 109G
c03n07 ok 1.3 18.6 18.6 4% 0.0 0 15072 429G 3.1G 340G
sg30 ok 1.3 1.0 1.0 5% 0.0 0 734 265G 2.4G 69.6G
c01n06 ok 1.3 20.0 20.6 5% 0.0 0 13242 432G 3.7G 351G
sg25 ok 1.5 1.0 1.7 5% 0.0 0 2e+5 258G 2.1G 108G
c06n03 ok 1.6 13.3 13.4 9% 0.0 0 14576 432G 3.7G 168G
sg02 ok 1.8 54.3 45.7 9% 0.0 2 18 239G 63.9M 78.5G
c06n01 ok 1.9 7.7 7.6 5% 0.0 0 3718 432G 3.8G 167G
c07n06 ok 2.0 14.3 14.2 12% 0.0 0 14956 431G 3.8G 166G
c05n05 ok 35.6 35.5 33.8 96% 0.0 0 15103 426G 2.9G 119G
c04n05 ok 35.7 35.8 35.4 94% 0.0 0 15972 427G 2.8G 114G
c06n06 ok 36.0 36.0 36.1 100% 0.0 0 14658 432G 3.7G 173G
c05n01 ok 37.4 38.3 37.5 97% 3.7 0 12160 432G 1.4G 141G
c06n12 ok 39.4 36.8 34.2 94% 0.0 0 7495 430G 3.6G 132G
c01n12 ok 45.1 48.2 46.8 82% 0.0 0 8000 432G 1.7G 278G
s002 ok 61.0 61.5 57.6 31% 0.0 1 739 1309G 3.1G 1.5T
s001 ok 70.9 73.7 91.8 19% 0.0 0 740 1286G 42.8M 1.3T
s006 ok 124.6 128.4 132.1 100% 0.0 0 432 1101G 3.5G 1.9T
s004 ok 128.1 125.3 123.3 65% 0.0 0 758 1318G 429M 1.8T
s003 ok 244.5 235.9 240.7 98% 0.0 1 3 1288G 2.8G 1.6T
bqueues¶
查看队列信息
$ bqueues
QUEUE_NAME PRIO STATUS MAX JL/U JL/P JL/H NJOBS PEND RUN SUSP
interactive 80 Open:Active - 3 - - 81 1 74 6
normal 30 Open:Active - - - - 19012 15984 3028 0
parallel 30 Open:Active - - - - 725 500 225 0
gpu 30 Open:Active - 10 - - 37 8 29 0
high 30 Open:Active - - - - 349 182 166 1
smp 30 Open:Active - 300 - - 6106 5166 940 0
q2680v2 30 Open:Active - 100 - - 5330 4784 546 0
- -u 查看所用所能使用的队列
- -m 查看节点所在的队列
- -l 查看队列的详细信息
$ bqueues -l smp QUEUE: smp -- huge memory jobs PARAMETERS/STATISTICS PRIO NICE STATUS MAX JL/U JL/P JL/H NJOBS PEND RUN SSUSP USUSP RSV PJOBS 30 0 Open:Active - 300 - - 6106 5156 950 0 0 0 737 Interval for a host to accept two jobs is 0 seconds HOSTLIMIT_PER_JOB 1 SCHEDULING PARAMETERS r15s r1m r15m ut pg io ls it tmp swp mem loadSched - - - - - - - - - - 29.2G loadStop - - - - - - - - - - 9.7G SCHEDULING POLICIES: NO_INTERACTIVE USERS: all HOSTS: s001 s002 s003 s004 s005 s006 RES_REQ: rusage[mem=10000] span[hosts=1] RESRSV_LIMIT: [mem=2000000] RERUNNABLE : yes
lsf skills for ai agent¶
通过将 lsf 使用文档、集群常用规则等提炼为 skills，可以协助用户更好得使用本集群。
Note
skills 会根据实际情况更新进化，因此下面安装 lsf skill 时建议使用软连接而不是拷贝的方式，以保证使用的 lsf skill 一直是最新版本。
这里以 Claude Code 为例，其它 AI agent 使用原则类似。安装配置 Claude Code，参考 Claude Code 使用。
安装配置完成后，将集群LSF使用的skills 链接安装到自己的 Claude Code 下。
$ mkdir ~/.claude/skills/
$ ln -s /public/home/software/opt/skills/lsf-ncpgr/ ~/.claude/skills/
❯ 目前有哪些已经安装的skills可用
● 根据系统提示，目前已安装并可用的 skills 如下：
┌───────────────┬─────────────────────────────────────────────────────────────────────────────────────┐
│ Skill 名称 │ 用途 │
├───────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ update-config │ 配置 Claude Code 的 settings.json，设置自动化行为（触发条件钩子） │
├───────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ simplify │ 检查已修改代码的可复用性、质量和效率，并修复问题 │
├───────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ loop │ 定期重复运行提示或斜杠命令（如 /loop 5m /foo），用于轮询状态等 │
├───────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ claude-api │ 使用 Claude API / Anthropic SDK / Agent SDK 构建 AI 应用 │
├───────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ lsf-ncpgr │ NCPGR 高性能计算集群 LSF 作业调度系统使用指南，帮助编写作业脚本、提交和管理计算任务 │
└───────────────┴─────────────────────────────────────────────────────────────────────────────────────┘
你可以使用 /skill-name 或 Skill 工具来调用这些技能。
❯ 目前集群上还有多少资源可用
● Skill(lsf-ncpgr)
⎿ Successfully loaded skill
● 根据 LSF 使用指南，我来帮你查看当前集群的可用资源：
● Bash(bhosts | grep -E "ok|closed|STATUS")
⎿ HOST_NAME STATUS JL/U MAX NJOBS RUN SSUSP USUSP RSV
c01n01 ok - 36 18 18 0 0 0
c01n02 closed - 36 36 36 0 0 0
… +62 lines (ctrl+o to expand)
● 当前集群可用资源统计
CPU 计算节点（36核/节点）：
- 空闲节点: 24 个节点状态为 ok，共有 459 个空闲核心
- 已占满节点: 大部分节点 (closed 状态) 核心已被占满
GPU 节点：
┌───────┬────────┬──────┬──────┬──────────┐
│ 节点 │ 总核心 │ 已用 │ 空闲 │ GPU 空闲 │
├───────┼────────┼──────┼──────┼──────────┤
│ gpu01 │ 36 │ 4 │ 32 │ ？ │
├───────┼────────┼──────┼──────┼──────────┤
│ gpu02 │ 128 │ 28 │ 100 │ ？ │
├───────┼────────┼──────┼──────┼──────────┤
│ gpu03 │ 192 │ 134 │ 58 │ ？ │
├───────┼────────┼──────┼──────┼──────────┤
│ gpu04 │ 192 │ 124 │ 68 │ ？ │
└───────┴────────┴──────┴──────┴──────────┘
大内存节点 (smp/high 队列)：
┌──────┬────────┬─────────────┐
│ 节点 │ 总核心 │ 空闲 │
├──────┼────────┼─────────────┤
│ s001 │ 192 │ 1 │
├──────┼────────┼─────────────┤
│ s002 │ 192 │ 2 │
├──────┼────────┼─────────────┤
│ s003 │ 192 │ 9 │
├──────┼────────┼─────────────┤
│ s004 │ 192 │ 2 │
├──────┼────────┼─────────────┤
│ s005 │ 96 │ 2 │
├──────┼────────┼─────────────┤
│ s006 │ 96 │ 0 │
├──────┼────────┼─────────────┤
│ 总计 │ - │ 16 空闲核心 │
└──────┴────────┴─────────────┘
---
汇总：
- 总计空闲 CPU 核心: ≈ 675 核
- 建议：根据 LSF 规范，申请 2-4 核更容易被立即调度；如果你需要更多核心，当前也有节点能满足 8-16 核的需求
需要我帮你进一步查看各队列的使用情况吗？
❯ 写一个lsf测试脚本并提交
● 我来帮你写一个 LSF 测试脚本并提交。按照规范，我会使用 .lsf 后缀，并遵循极简编写原则：
● Write(test_job.lsf)
⎿ Wrote 28 lines to test_job.lsf
1 #!/bin/bash
2 #BSUB -J test_job
3 #BSUB -q normal
4 #BSUB -n 2
5 #BSUB -R "span[hosts=1]"
6 #BSUB -o %J.out
7 #BSUB -e %J.err
8
9 echo "=== Job started at $(date) ==="
10 echo "Running on host: $(hostname)"
… +18 lines (ctrl+o to expand)
● 现在提交作业：
● Bash(bsub < test_job.lsf)
⎿ Job <71370334> is submitted to queue <normal>.
● 作业已成功提交！作业ID: 71370334，队列: normal。让我检查一下作业状态：
● Bash(bjobs 71370334)
⎿ JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
71370334 user RUN normal mn01 2*c05n14 test_job Apr 6 00:48
● ✅ **作业已成功提交并开始运行！
信息：
- 作业ID: 71370334
- 队列: normal
- 状态: RUN (正在运行)
- 执行节点: c05n14
- 核心数: 2
- 输出文件: `71370334.out
- 错误文件: `71370334.err
你可以用以下命令查看实时输出：
bpeek 71370334
或查看完整输出：
cat 71370334.out
❯ 71370479 这个作业为何一直在排队没有运行
● 让我查看一下这个作业排队的原因：
● Bash(bjobs -p 71370479)
⎿ JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
71370479 user PEND normal mn01 test_job Apr 6 00:56
Not enough job slot(s): 35 hosts;
● 原因找到了：Not enough job slot(s) - 没有单个节点有 40 个空闲核心。
问题分析：
- 集群每个 CPU 计算节点最多只有 36 核，你申请了 40 核，自然无法满足
- 即使整个集群加起来空闲核心不少，但你用了 -R "span[hosts=1]" 限制必须在单节点运行，所以必须在同一个节点凑够 40 个空闲核心才能调度
- 当前集群没有任何一个节点有 40 个空闲核心，所以一直排队
解决建议：
1. 把核数降到 36 核以内（比如 8-16 核），然后重新提交
2. 如果你确实需要更多核心，可以使用 MPI 多节点并行，但生物信息软件绝大多数不支持跨节点
你想修改核数重新提交吗？
常见问题¶
- 程序运行异常但没有作业没有退出，最常见于 hisat2 比对，使用 bpeek 查看作业日志，报错如下
(ERR): "/public/home/username/database/reference/genome" does not exist Exiting now ...
本站总访问量 次