简介：openlava 4.0 源码安装包面向希望理解 HPC 集群调度与资源管理的开发者、运维人员和学习者，虽已停止官方维护，但其调度模型仍具参考价值，IBM LSF 亦由其发展而来。压缩包共 501 个文件、约 1.65MB，以 250 个 C 源文件和 65 个头文件为核心，配合 man 手册、automake/configure 构建脚本、m4 宏及 MPICH/OpenMPI 启动封装，构成较完整的源码、编译与文档体系，便于按模块阅读守护进程、命令工具和库函数之间的组织关系。内容可用于梳理作业提交、队列查询、主机负载监控、作业历史与账户统计等命令语义，也可从源码层面观察调度器、资源限制和集群通信的实现思路，适合搭建小型实验环境并对照手册验证配置。已有 1604 人学习或下载，可作为集群管理入门、源码阅读、课程实验和二次开发准备的参考材料。
1. 从一台节点到可调度队列：openlava-4.0.tar.gz 的定位
三台机器上手动 ssh 跑任务，谁先登录谁占满 CPU，这种小集群的日常，靠人喊排队迟早出错。openlava-4.0.tar.gz 是一个源码包，拆开之后落地的核心是 openlava 集群管理里那条从主机解析、守护进程、队列到作业回写的链路，不是某个单机命令。它提供 LSF 风格的作业调度：主节点管主机、队列和资源，计算节点执行作业，适合几台到几十台 Linux 机器的小集群、教学实验和调度策略验证。它不适合被当成容器编排或跨机房调度器，前置条件也明确：统一用户、主机名可解析、安装目录各节点一致。愿意按源码包一步步编译和配文件的人，能把它跑成一套可用的批处理队列。
2. 解包前先看依赖：openlava 4.0 的编译环境与主机名基线
2.1 资源包结构与编译依赖核对
拿到 tar.gz 先别急着 configure。源码包通常包含 configure、Makefile.in、src、doc 和 etc 模板，安装路径、守护进程目录、配置模板都从这些文件里长出来。openlava 的调度链路由 LIM、MBD、RES、sbatchd 等守护进程组成，编译阶段缺一个开发库，后面就可能卡在 make 或启动阶段。常见做法是先确认编译工具链和基础库，再决定要不要装 tcl/tk、ncurses 这类依赖；不同发行版的包名不一样，下面的命令只作为核对起点，缺什么按 configure 报错补。
# 先看包内顶层结构，确认 configure 和 etc 模板存在 tar -tzf openlava-4.0.tar.gz | head -40 # 核对编译工具链和系统基础信息 gcc --version make --version getconf GNU_LIBC_VERSION uname -m这段命令的逻辑是先看包内结构，避免解压后发现少了 configure 或模板文件；再确认 gcc、make 和 libc 版本。参数上head -40只用于快速看顶层，不是完整清单；uname -m用来确认节点架构一致，后面 lsf.cluster 里的 model 字段要和实际机器对得上。如果编译节点和计算节点架构不同，不要图省事共用同一个安装目录，否则可执行文件会在另一类机器上翻车。
依赖安装示例只作参考，包名以当前发行版仓库为准：
# Debian/Ubuntu 系常见依赖，缺 tcl/tk 时 configure 会报错 sudo apt-get update sudo apt-get install -y build-essential libtool automake autoconf \ libncurses5-dev tcl-dev tk-dev这里安装的是编译工具、自动构建工具和常见终端/图形库开发包。build-essential提供 gcc、make 等基础工具，libtool、automake、autoconf用于处理构建脚本，libncurses5-dev、tcl-dev、tk-dev是 openlava 构建过程中可能被探测到的依赖。不要一次性把所有能想到的包都装上，先按最小集合走，configure 报缺什么再补，这样后面排查编译错误时心里有数。若使用的是另一类发行版，用对应的包管理命令替换，不要照抄包名。
选型上，源码包的好处是安装路径可控，可以把/opt/openlava固定成所有节点一致的目录；代价是依赖和配置要自己兜底。编译前先确认磁盘空间和权限，/opt/openlava不要放在某个用户的家目录下，否则作业账号切换后路径就失效。安装用户也建议统一，常见做法是创建一个专用账号clusteradm，所有节点 UID/GID 保持一致。
2.2 主机名、时钟与用户体系：集群调度的三条底线
openlava 用主机名标识节点，配置文件里的 HOSTNAME 必须和hostname -s的输出一致。很多“lsid 正常但 bhosts 全 unavail”的问题，根子不在调度器，而在短名和长名混用、/etc/hosts 缺记录、或者某台机器改了主机名但配置没跟着改。小集群用 /etc/hosts 就够，关键是要在所有节点上保持一致；不要 master 用短名、compute 用 FQDN，最后配置里写的是第三种写法。
# 所有节点保持一致的主机名解析，IP 用文档保留地址示例 sudo tee -a /etc/hosts >/dev/null <<'EOF' 192.0.2.10 master01 192.0.2.11 node01 192.0.2.12 node02 EOF # 每台节点核对短名和解析结果 hostname -s getent hosts master01 node01 node02这段配置把 master01、node01、node02 固定到 /etc/hosts，IP 段只是示例，实际替换成自己的内网地址。hostname -s用来确认本机短名，getent hosts用来确认解析顺序和结果。注意不要在 hosts 里给同一台机器写多个别名后又混着用，配置里用哪个名字，后续命令和日志里就统一用哪个名字。主机名解析不通时，LIM 之间握手会失败，表现往往不是“报错很明确”，而是节点一直不可用。
时钟也要统一。作业记账、日志时间线和bhist里的时间都依赖节点时钟，偏差太大时排查会变成黑匣子。常见做法是内网起一个时间同步服务，或者至少让所有节点指向同一个时间源；没有条件时也要在部署前手工校时，并把差异控制在可接受范围内。统一用户同样重要：提交作业的账号、运行脚本的账号、共享目录的属主必须能对上，否则会出现“主节点能读、计算节点 Permission denied”的血泪经验。
# 核对时钟同步状态和统一账号 timedatectl status id clusteradm getent passwd clusteradmtimedatectl status看系统时间同步是否启用，id clusteradm看 UID/GID 和附加组，getent passwd clusteradm确认各节点解析到的是同一个账号。参数上不需要追求毫秒级，但不要让节点之间差出几分钟。统一账号不要只在一台机器上建，计算节点也要有相同 UID/GID；如果共享目录通过 NFS 挂载，UID 不一致会直接变成权限问题。
2.3 从 tar.gz 到可执行文件：configure、make、install 的完整命令
安装路径先定下来，常见是/opt/openlava，所有节点保持同一路径。编译可以在 master 上做，也可以在一台同架构的构建机上做，然后把安装目录同步或共享出去。--prefix不要随手改成/usr/local，否则多版本共存时容易和系统包混在一起；安装目录也不要带用户名和家目录，作业进程切换后路径会变。
# 解包、配置、编译、安装，prefix 固定为所有节点一致路径 cd /opt/src tar -xzf openlava-4.0.tar.gz cd openlava-4.0 ./configure --prefix=/opt/openlava make -j"$(nproc)" sudo make install./configure --prefix=/opt/openlava决定安装根目录，后面的 bin、sbin、etc、log 都会落在这个前缀下。make -j"$(nproc)"用当前 CPU 核数并行编译，能缩短构建时间；如果内存较小，核数不要开太高，否则可能在链接阶段被 OOM 打断。sudo make install写入/opt/openlava，执行前确认目录权限和磁盘空间。安装完成后不要急着启动，先找环境脚本和配置文件模板。
# 安装后先定位环境脚本和 etc 模板 ls /opt/openlava/etc find /opt/openlava -maxdepth 2 -name '*openlava*' -o -name 'lsf.conf' # 常见环境脚本位置之一，若不存在按上一条 find 结果替换 source /opt/openlava/etc/openlava.sh which bsub lsid这段命令先看 etc 下有哪些模板，再找环境脚本。source之后 PATH 里应该能出现bsub、bjobs、bhosts等命令；which bsub用来确认当前 shell 用的是哪个安装目录，lsid用来确认主节点守护进程是否已经起来。环境脚本路径在不同构建里可能不同，不要硬编码一个不存在的路径；找不到时用find在/opt/openlava下按名字定位。参数上，-maxdepth 2限制搜索深度，避免扫到大量源码文件。
编译阶段常见的失败是缺头文件或库文件，configure 日志里会给出缺失项；make 阶段常见的是链接失败或并行编译竞争，先把-j降下来重跑，确认不是并行导致后再看错误行。安装完成后如果lsid找不到命令，先检查source是否生效、PATH 是否包含/opt/openlava/bin，再检查安装目录是否真的写入了可执行文件。这个阶段不要跳过验证，后面配置集群时再回头查编译问题，成本会高很多。
3. 集群配置文件怎么落地：lsf.cluster、lsf.shared 与节点角色
3.1 三个配置文件的分工：静态拓扑、共享资源和本机环境
openlava 的配置不要混在一个文件里。lsf.conf更偏本机环境，告诉守护进程配置目录、可执行目录、日志目录和集群名；lsf.shared定义资源名和资源类型，属于集群共享的资源字典；lsf.cluster.<集群名>描述主机拓扑、主机角色和队列。三者分工清楚，改错位置时现象往往很迷惑：队列参数写进了本机文件，结果只有一台机器生效；资源名只在 master 上改，计算节点不认识，作业就一直排队。
| 文件 | 主要作用 | 改完后要做什么 |
|---|---|---|
lsf.conf | 本机环境、目录、集群名 | 同步到所有节点并重启相关守护进程 |
lsf.shared | 资源名、类型、资源字典 | 所有节点保持一致，新增资源要同步 |
lsf.cluster.<name> | 主机拓扑、主机角色、队列 | 主节点重点维护，变更后核对 bhosts/bqueues |
选型上，小集群先用单主节点结构，把 master01 作为管理节点，node01、node02 作为计算节点。不要一开始就把所有机器都配成管理角色，除非确实要验证高可用；多管理角色会引入选主和配置一致性问题，排错成本比收益高。配置目录建议通过 NFS 共享，或者用配置管理工具同步，避免“每台机器手工改一遍，最后不知道哪台是最新”的后悔药。
3.2 主节点与计算节点的配置样例
先写本机环境。下面只是常用项示例，实际路径以安装结果为准：
# /opt/openlava/etc/lsf.conf LSF_ENVDIR=/opt/openlava/etc LSF_SERVERDIR=/opt/openlava/sbin LSF_BINDIR=/opt/openlava/bin LSF_LIBDIR=/opt/openlava/lib LSF_LOGDIR=/opt/openlava/log LSF_CLUSTERNAME=cluster1LSF_ENVDIR指向配置目录，LSF_SERVERDIR指向守护进程目录，LSF_BINDIR指向客户端命令目录，LSF_LOGDIR是日志落点，LSF_CLUSTERNAME要和集群拓扑文件名对应。参数不要凭感觉改，路径必须真实存在；日志目录要提前建好并给统一账号写权限。这个文件在每台节点上都要一致，至少集群名和目录不能各写各的。
集群拓扑文件lsf.cluster.cluster1里先放主机表。字段名以包内模板为准，下面演示的是常见写法：
# /opt/openlava/etc/lsf.cluster.cluster1 Begin Cluster ClusterName cluster1 End Cluster Begin Host HOSTNAME model type server r1m master01 x86_64 linux 1 - node01 x86_64 linux 1 - node02 x86_64 linux 1 - End HostHOSTNAME必须和hostname -s一致，model写架构，type写系统类型，后面的管理角色列按模板含义填。不要把主机名写成 IP，也不要把长短名混用。主机表里多一行少一行，bhosts的结果就会不一样；新增节点时先确认解析，再改这个文件，最后重启或让守护进程重新加载。队列定义可以放在同一个拓扑文件里，下面是一个普通队列样例：
# 队列样例，字段以包内模板为准 Begin Queue QUEUE_NAME normal PRIORITY 30 NICE 10 USERS all HOSTS all PROC_LIMIT 8 MEMLIMIT 16G End QueueQUEUE_NAME是提交时-q指定的名字，PRIORITY影响队列之间的调度优先级，NICE影响同优先级下的调整，USERS和HOSTS控制可用范围，PROC_LIMIT限制单作业可用的进程/槽位，MEMLIMIT限制内存。小集群不要把队列拆得太碎，先有一个 normal 队列跑通，再按项目加长任务队列或高内存队列。lsf.shared先沿用模板里的资源定义，新增资源名时三处保持一致，否则调度器不认识这个资源。
3.3 启动、验证与一条作业从提交到完成的链路
启动顺序要按守护进程的依赖来。常见做法是先起 LIM，再起 RES，然后起 MBD，最后确认 sbatchd。命令路径按安装目录替换，执行用户用统一账号：
# 启动顺序：LIM -> RES -> MBD -> sbatchd sudo -u clusteradm /opt/openlava/bin/lsadmin limstartup sudo -u clusteradm /opt/openlava/bin/lsadmin resstartup sudo -u clusteradm /opt/openlava/bin/badmin mbdstartup sudo -u clusteradm /opt/openlava/bin/badmin sbatchd # 验证主节点和主机状态 lsid bhosts bqueueslimstartup起的是 LIM，负责主机间通信；resstartup起 RES；mbdstartup起 MBD，负责作业管理；sbatchd负责作业执行侧。lsid看主节点身份，bhosts看主机是否可用，bqueues看队列是否加载。启动失败时先看日志目录，不要反复重启；日志里通常会指出配置文件哪一行解析失败，或者哪个目录没有权限。停止顺序反过来：先停 MBD，再停 RES 和 LIM。
验证作业链路用一个最小任务，不要一上来就提交大作业：
# 提交一个单槽作业，输出文件按作业 ID 命名 bsub -q normal -n 1 -o /share/logs/test.%J.log /bin/hostname # 查看作业详情和输出 bjobs -l cat /share/logs/test.*.log-q normal指定队列，-n 1申请一个槽位，-o把标准输出写到共享目录，%J会被替换成作业 ID。bjobs -l看作业状态、执行主机和挂起原因，输出文件里应该出现某台计算节点的主机名。如果作业一直 PEND，先看bjobs -l里的 PENDING REASON，再看bhosts是否有可用主机，最后看队列限制。链路跑通的标准不是“bsub 返回了作业号”，而是作业真的在计算节点执行并把结果写回共享目录。
4. 队列与资源模型：把 CPU、内存、槽位映射成可调度参数
4.1 队列定义与优先级：bqueues 背后的参数
队列不是虚拟分区，更像策略容器。它决定哪些用户和主机可以用、单作业能拿多少槽位和内存、队列之间的优先级怎么排。很多人把队列当成“项目分组”，一口气建十几个，结果调度关系复杂到自己也说不清。小集群先建两三个队列就够：normal 跑日常任务，long 跑长任务，highmem 跑大内存任务。每个队列的参数都要能对应到实际资源，不然就是给自己埋坑。
# 查看队列详情，重点看优先级、限制和可用主机 bqueues -l normalbqueues -l会展开队列参数，重点看 PRIORITY、NICE、PROC_LIMIT、MEMLIMIT、USERS、HOSTS 这些项。PRIORITY 数字越大，队列之间越容易先被调度；NICE 用于同优先级下的调整；PROC_LIMIT 和 MEMLIMIT 是单作业上限，不是整台机器的上限。不要把队列优先级当成绝对抢占，普通队列之间更多是排序和公平份额在起作用。参数改完后要重新加载或重启 MBD，具体动作按当前版本的配置机制走，改完必须用bqueues -l复核。
| 参数 | 含义 | 常见误用 |
|---|---|---|
PRIORITY | 队列调度优先级 | 设得很高但没考虑用户公平份额 |
NICE | 同优先级下的调整值 | 和系统 nice 混为一谈 |
PROC_LIMIT | 单作业进程/槽位上限 | 设得太小导致多进程作业永远 PEND |
MEMLIMIT | 单作业内存上限 | 设得比主机可分配内存还大 |
USERS/HOSTS | 可用用户和主机范围 | 新节点没加进去，作业找不到主机 |
选型理由很简单：队列参数要跟硬件和作业形态对齐。四核机器上把 PROC_LIMIT 设成 64，作业会一直等资源；内存只有 16G 却把 MEMLIMIT 写成 32G，调度器会认为队列允许，但主机资源永远满足不了。常见做法是先按单机最小规格设保守值，跑一批真实作业后再调，不要一开始就把上限拉满。
4.2 资源限制与作业提交模板
提交作业时把资源需求写清楚，比事后猜 PEND 原因省事。-n是槽位，-R "rusage[mem=...]"是资源预留，span[hosts=1]限制作业落在同一台主机。小集群里跨主机并行很容易遇到通信和共享目录问题，除非脚本本身支持多机，否则先限制单主机。
# 提交四槽作业，限制单主机，预留内存，输出到共享日志目录 bsub -q normal -n 4 \ -R "rusage[mem=2048]" \ -R "span[hosts=1]" \ -o /share/logs/job.%J.out \ -e /share/logs/job.%J.err \ /share/scripts/run_task.sh-n 4申请四个槽位，rusage[mem=2048]表示每个任务预留 2048MB 内存，span[hosts=1]要求同一主机，-o和-e分别写标准输出和错误输出，%J是作业 ID 占位符。参数不要只看单位，内存单位要和队列、主机资源口径一致；如果脚本实际会开更多进程，-n要覆盖进程数，否则作业跑起来后可能被限制。输出目录必须是所有节点都能写的共享目录，否则作业完成但日志找不到。
也可以用 BSUB 注释模板把参数写进脚本：
#!/bin/bash #BSUB -q normal #BSUB -n 4 #BSUB -R "rusage[mem=2048]" #BSUB -R "span[hosts=1]" #BSUB -o /share/logs/job.%J.out #BSUB -e /share/logs/job.%J.err # 下面写实际任务，路径用共享目录，不要依赖个人家目录 /share/scripts/run_task.sh提交时用bsub < job.lsf，注释行会被解析成作业参数。好处是参数和脚本放在一起，版本管理时不容易丢；坏处是复制脚本时容易把旧参数带过去。参数说明同上，额外注意脚本第一行和注释行之间不要插空行，否则部分解析器可能不认。实际任务路径不要写~/work，计算节点上的家目录未必挂载，统一放到/share下更稳。
4.3 常见调度参数调优：不要只看 bjobs 的 PEND
bjobs显示 PEND 只是结果，原因要看详情。常见顺序是先看作业的 PENDING REASON，再看主机资源，再看队列限制，最后看用户公平份额。不要一看到 PEND 就加队列优先级，很多时候是作业请求了 8 个槽位，而集群里最大空闲主机只有 4 个；或者是内存预留超过单机可分配量。
# 查看所有用户的挂起作业和原因 bjobs -u all -p bjobs -l <JOBID> # 查看主机和队列的可用资源 bhosts -l node01 bqueues -l normal lsload -lbjobs -u all -p只看挂起作业，bjobs -l展开单个作业的详情，bhosts -l看主机资源与状态，bqueues -l看队列限制，lsload -l看负载。参数上，-p是只看 PEND，适合日常巡检；-l信息多，适合定位问题。若 PENDING REASON 显示资源不足，先核对-n和rusage[mem]是否超过主机容量；若显示队列关闭或用户限制，去查队列参数和用户份额。调优不要一次改多个参数，改一个、跑一轮、看结果，否则出问题不知道是哪一项引起的。
常见调优手法是把大作业和小作业分开队列，给长任务单独设 RUN_WINDOW 或优先级，给大内存任务单独设 MEMLIMIT。不要用队列优先级去解决资源不足，优先级只能改变排序，不能凭空造出 CPU 和内存。内存限制建议留 10% 到 20% 余量，给系统进程和临时峰值；PROC_LIMIT 不要设得比单机最大槽位还小太多，否则多进程作业会长期排队。调参前先记录一组基线：bhosts、bqueues -l、bjobs -u all，改完对照看变化。
5. 避坑与排查：openlava 4.0 落地时最容易翻车的五件事
5.1 现象：lsid 正常但 bhosts 显示 unavail
这是最常见的一类翻车。lsid能看到主节点，说明本机 LIM 至少起来了，但bhosts里计算节点全是 unavail，说明主节点和计算节点之间的握手没通。原因通常在三处：主机名解析不一致，配置文件里的 HOSTNAME 和实际短名对不上；计算节点的 LIM 没启动或启动失败；防火墙或网络策略挡住了守护进程端口。先不要改队列，按主机维度查。
# 在主节点和计算节点分别核对解析、进程和主机状态 getent hosts node01 ps -ef | grep -E 'lim|mbd|sbatchd|res' bhosts -l node01getent hosts确认解析结果，ps -ef看守护进程是否还在，bhosts -l看主机不可用的详细状态。解决顺序是先把主机名统一，再在计算节点启动 LIM，最后检查网络。计算节点上的配置文件要和主节点一致，尤其是集群名和 LSF_ENVDIR。不要在 unavail 状态下反复提交作业，作业会一直 PEND，日志里也看不出真正原因。
5.2 现象：作业一直 PEND，PENDING REASON 为空或 load
PEND 原因为空或显示 load 时，很多人会误以为调度器坏了。实际更常见的是资源请求超过主机容量，或者队列限制把作业卡住了。比如申请 8 个槽位，但每台机器只有 4 个；或者rusage[mem=8192]超过单机可分配内存。另一种情况是队列的 PROC_LIMIT 小于作业请求，作业永远无法满足。
# 定位作业挂起原因 bjobs -l <JOBID> bqueues -l normal bhosts -l先看bjobs -l里的 PENDING REASON，再看bqueues -l的 PROC_LIMIT、MEMLIMIT、USERS、HOSTS，最后看bhosts -l的主机资源。解决方法是把作业请求降到主机可满足的范围，或者把队列限制调到合理值。不要为了让作业跑起来就把所有限制清零，限制清零后大作业可能把整台机器拖垮。参数调整后重新提交，不要在原作业上反复重试。
5.3 现象：多节点脚本找不到命令或权限错误
主节点能跑，计算节点报command not found或Permission denied，通常是安装目录没有共享、环境变量没统一、UID 不一致。openlava 把作业派到计算节点执行，计算节点上的脚本路径、命令路径、共享目录权限都要能对上。尤其是自己编译的软件放在/opt下，却只装在 master 上，node01 上当然找不到。
# 在计算节点核对命令路径、账号和共享目录 ssh node01 'source /opt/openlava/etc/openlava.sh; which bsub; id' ls -ld /share /share/scriptsssh在这里用于排查环境，不是作业执行的唯一依赖；which bsub看 PATH，id看账号 UID/GID，ls -ld看共享目录权限。解决方法是把安装目录做成 NFS 共享或同步到所有节点，统一环境脚本，统一账号 UID/GID。脚本里不要写个人家目录路径，统一用/share这类所有节点可见的目录。权限问题不要用chmod 777糊过去，按账号和组授权，后面才不会被安全审计卡住。
5.4 现象：重装后队列配置回滚
重装 openlava 后队列突然变回默认值，或者新增主机消失，常见原因是配置只改了 master 本地文件，没有纳入备份和版本管理。make install可能覆盖 etc 下的模板，手工改的内容如果没备份，重装后就找不回来。另一个原因是配置目录没有共享，每台机器各有一份，改了一台以为全集群生效。
# 变更前备份配置，变更后记录差异 sudo cp -a /opt/openlava/etc /opt/openlava/etc.bak.$(date +%F) sudo diff -ru /opt/openlava/etc.bak.* /opt/openlava/etc || truecp -a保留权限和时间戳，date +%F生成日期后缀，diff -ru用来对比变更前后。解决方法是把 etc 纳入版本管理或至少每日备份，安装前先备份，安装后对比恢复。配置目录如果通过 NFS 共享，要确认所有节点挂载的是同一份，不要本地又留一份缓存。队列参数变更后跑一次bqueues -l和bhosts基线，确认没有回滚。
5.5 现象：日志增长和进程残留
跑一段时间后/opt/openlava/log增长很快，或者停止服务后ps里还能看到 lim、mbd、sbatchd 残留。日志增长通常是没做轮转，进程残留往往是停止顺序不对或异常退出。不要直接kill -9所有进程，先按正常顺序停，确认停不掉再查日志和端口。
# 正常停止顺序：先作业管理，再资源，再 LIM sudo -u clusteradm /opt/openlava/bin/badmin mbdshutdown sudo -u clusteradm /opt/openlava/bin/lsadmin resshutdown sudo -u clusteradm /opt/openlava/bin/lsadmin limshutdown # 检查残留进程 ps -ef | grep -E 'lim|mbd|sbatchd|res' | grep -v grep停止顺序和启动相反，先停 MBD，再停 RES 和 LIM。ps -ef这条命令过滤出相关守护进程，grep -v grep去掉 grep 自身。解决日志增长用 logrotate 或定时归档，保留最近若干天；解决残留先看日志里有没有配置解析失败或端口占用，再决定是否手工清理。不要在没有备份日志的情况下删日志，出问题时那是唯一的黑匣子。
6. 把 openlava 4.0 用稳：监控、备份与一次小规模压测的收尾技巧
日常巡检不需要盯十几个命令，先看三个面：主机是否可用、队列是否正常、作业是否在动。下面这张表可以贴在运维笔记里，每天花两分钟跑一遍。
| 监控对象 | 命令 | 判读重点 |
|---|---|---|
| 主机 | bhosts | 是否有 unavail、负载是否长期打满 |
| 队列 | bqueues -l | 限制是否被改、可用主机是否缺失 |
| 作业 | bjobs -u all | PEND 是否集中、是否有异常长跑作业 |
压测不要拿真实大作业试，先用短睡眠作业打一轮，观察调度和日志是否正常：
# 提交 20 个短作业，观察排队、执行和输出回写 for i in $(seq 1 20); do bsub -q normal -n 1 -o /share/logs/smoke.%J.out /bin/sleep 30 done bjobs -u all这段脚本循环提交 20 个单槽作业，%J让每个作业输出独立文件，bjobs -u all看整体排队情况。压测后把作业清理掉，检查/share/logs是否按预期生成文件，再对照bhosts看负载是否回落。配置备份也放在同一轮里做，改队列前先备份 etc，改完用diff对比，确认只动了想动的行。从那以后我每次改lsf.cluster.*前都先备份 etc、跑一遍bhosts和bqueues基线，再动队列参数；这套习惯比事后翻日志省太多时间。希望帮到你。
本文还有配套的精品资源，点击获取
